LABORATORY  FOR 
COMPUTER  SCIENCE 


MASSACHUSETTS 
INSTITUTE  OF 
TECHNOLOGY 


MIT/LCS/TR-307 


PRELIMINARY  REPORT  ON  THE 
LARCH  SHARED  LANGUAGE 


J.V.  Guttag 
J.J.  Horning 


Approved  tor  pubne  rata 
Distribution  Unttmitad 


This  ri-M.Mrt.il  was  supported  in  pan  by  the  Defense  Advanced  Research  Projects 
Agent  \  of  the  Department  of  Defense  and  was  monitored  by  the  Office  of  Naval 
Keseart  h  under  Contract  No.  N00014  75  C  0661.  and  by  the  National  Science 

foundation  under  Grant  MGS  HI  19-iHb 

i 


K 


545  TECHNOLOGY  SQUARE.  CAMBRIDGE.  MASSACHUSETTS  02139 


63  &ao  S4 


Unclassified 


SECURITY  CLASSIFICATION  OF  THIS  PAOE  (Whan  Data  KM terod) 


|  REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

S.  RECIPIENT'S  CATALOG  NUMBER 

4.  TITLK  (mtd  kubHtlt) 

Preliminary  Report  on  The  Larch  Shared  Language 

S.  TYPE  OF  RFPORT  A  PERIOD  COVERED 

Interim  Research 

S.  PERFORMING  ORG.  REPORT  NUMBER 

MIT/LCS 

7.  AUTHORS 

John  V.  Guttag  and  J.  J.  Horning 

S.  CONTRACT  OR  GRANT  NUMBERf«> 

DARPA/DOD  N00014-75-C-0661 
NSF  MCS-811984  6 

••  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

MIT  Laboratory  for  Computer  Science 

545  Technology  Square 

Cambridge,  MA  02139 

^|j|||J|L^’)  inarm 

11-  CONTROLLING  OFFICE  NAME  ANO  ADDRESS 

DARPA/DOD/IPTO 

1400  Wilson  Boulevard 

Arllnqton.  VA  22209 

12.  REPORT  DATE 

October  1 983 

_ 55 _ 

Office  of  Naval  Research/Dept  of  Navy 

Information  Systems  Program 

Arlington,  VA  22217 

IS.  SECURITY  CLASS,  (ol  Orta  report) 

Unclassified 

IS*.  OECLASSI  FI  CATION /DOWNGRADING 
SCHEDULE 

IS.  DISTRIBUTION  STATEMENT  (ml  «k la  Report) 

ADoroved  for  Public  Release*,  distribution  is  unlimited. 

1  Aocesalon  For  ~~ — 

fills  muj  7p— 

17.  DISTRIBUTION  STATEMENT  (cl  the  abatract  entered  in  mock  20,  II  dltforont  from  Report)  j  uric  TAB 

J  Unannounced 
[  Justification  U  1 

Unlimited  r  ■ — ~  ~| 

IB.  supplementary  notes  - - 

/  0r  \ 

L?istrlbution7~'  - - j 

[AvallabllitjT^o^  j 

Di_.  !Avail  and/or"  1 

Dlst  !  Special  1 

IS-  KEY  WORDS  (Continue  an  rererae  aide  II  neceaaarr  and  Idantlly  by  block  ntmebor) 

Algebraic  specification,  specification  language 

jfl  I  | 

20.  ABSTRACT  (Continue  on  roeotao  aide  If  nocoaaary  and  Identity  by  block  number) 


Each  member  of  the  Larch  family  of  formal  specification  languages  has  a  com¬ 
ponent  derived  from  a  programming  language  and  another  component  common  to  all 
programming  languages.  We  call  the  former  interface  languages,  and  the  latter 
the  Larch  Shared  Language. 

This  report  presents  version  1.0  of  the  Larch  Shared  Language.  It  begins  with 

. . .continued 


20.  Continued 


a  brief  Introduction  to  the  Larch  Project  and  the  Larch  family  of 
languages.  The  next  chapter  presents  most  of  the  features  of  the  Larch 
Shared  Language  and  briefly  discusses  how  we  expect  these  features  to  be 
used.  It  should  be  read  before  reading  either  of  the  remaining  two 
chapters,  which  are  a  self-contained  reference  manual  and  a  set  of 
examples. 


MCVMITV  CL  AM  MC AVION  Of  TMN  PAMfMbaa  tM  (MwmQ 


Preliminary  Report  on  The  Larch  Shared  Language* 


J.  V.  Guttag 

MIT  Laboratory  for  Computer  Science 
545  Technology  Square 
Cambridge,  Massachusetts  02139 


J.  J.  Homing 
Xerox  Corporation 
3333  Coyote  HiH  Road 
Palo  Alto,  California  94304 


October  1963 


ABSTRACT 


Each  member  of  the  Larch  family  of  formal  specification  languages  has  a  component  Derived  from  a 
programming  language  and  another  component  common  to  all  programming  languages.  AVe  call  the  former 
interface  languages,  and  the  latter  the  Larch  Shared  Language. 


"7^  a-  ^ 

inent  peri' 
s.  JAfe  can 


rS 


This  report  presents  version  1.0  of  the  Larch  Shared  Language.  It  begins  with  a  brief  introduction  to  the 

Larch  Protect  and  the  Larch  family  of  languages  The  next  chapter  presents  most  of  the  features  of  the  Larch 

* 

Shared  Language  and  briefly  discusses  how  we  expect  these  features  to  be  used.  It  should  be  read  before 
reading  either  of  the  remaining  two  chapters  which  are  a  self-contained  reference  manual  and  a  set  of 


Keywords:  Algebraic  specification,  specification  language 


OJ.  V.  Guttag  and  J.  J.  Homing 


*TMe  work  was  supported  a  MB'*  Laboratory  tor  Computer  Sc  tones  by  DARPA  under  contract  NOOO14-75-C-O061,  and  by  Ste 
taSonal  Science  Foundation  under  Grant  MCS-S119S4  a  and  at  Ste  Xerox  Palo  Alto  fteaeareh  Canter  by  the  Computer  Science 


the  Larch  Shared  Language 


able  of  Coafteats 

CMnt 

The  Larch  Family  af  Languages 
Status  and  Plans 

Aa  latrodactioa  to  the  Larch  Shared  Laapage 

Simple  Algebraic  Specifications 
Getting  Richer  Theories 


Consequences  and  Exemptions 
Constrains  Clauses 

Implicit  Signatures  and  Partial  OpForms 


taixflx  Operators 


THE  Larch  Shared  Language 


Boolean  Terms  as  Equations 
External  References 
Modifications 

Implicit  Incorporation  of  Boolean.  IfThenElse.  and  Equality 
Semantic  Checking 

Reference  Grammar  for  Lank  Shared  Language 

Towaide  a  Larch  Shared  Uagaage  Handbook 

^  ■*»  -  - 

nfQQCC 

Conventions 

Basic  Properties  of  Single  Operators.  Including  Binary  Relations 

Ordering  Relations 

Group  Theory 

Simple  Numeric  Types 

Simple  Data  Structures 

Container  Properties 

Container  Classes 

Generic  Operators  km  Conudnen 

Nonlinear  Structures 

Rings  Fields,  and  Numbers 

Lattices 

Enumerated  Data  Types 
Display  Traits 


4 


The  Larch  Shared  Language 


Contact 

lit  Luck  F amfly  of  fimm 

The  Laidi  Project  is  developing  tods  and  techniques  intended  to  aid  in  the  productive  use  of 
formal  specifications  of  systems  containing  computer  programs.  Many  of  its  premises  and  goals  are 
diacuarod  in  [Guttag,  Homing,  and  Wing  82]. 

We  view  a  system  as  consisting  of  a  state  and  mechanisms  for  dunging  and  extracting  information 
from  that  state.  We  choose  to  define  the  information  contained  in  the  state  without  reference  to 
either  how  dial  information  was  created  or  how  it  will  be  used.  Our  specifications  consist  of  two 
puts.  In  one,  we  specify  die  properties  of  values  that  may  appear  in  system  states,  and  in  the  second, 
the  program  modules  that  deal  with  those  states. 

A  nuqor  component  of  the  Larch  Project  is  a  family  of  specification  languages.  Each  Larch 
Unyiy  hag  g  component  particular  to  a  specific  programming  language  and  another  component 
common  to  all  programming  We  call  the  former  interface  languages,  and  die  latter  the 

shared  language. 

We  use  the  interfere  i««g»«g*«  to  specify  program  modules.  Specifications  of  the  interface  that 
one  module  presents  to  other  modules  often  rely  on  notions  specific  to  the  programming  language. 

its  denotable  values  or  its  exception  handling  mechanisms.  Each  interface  language  deals  with 
what  can  be  observed  about  die  behavior  of  programs  written  in  a  specific  programming  language. 
Its  simplicity  or  complexity  is  a  direct  consequence  of  die  simplicity  or  complexity  of  die  observable 
state  and  state  transformations  of  that  programming  language. 

The  dialed  la"g111T  is  algebraic.  It  is  used  to  specify  abstractions  that  are  independent  of  both 
the  program  stale  and  the  programming  language  The  operators  defined  by  an  algebraic  specification 
appear  in  specifications  written  in  the  interface  languages,  and  in  reasoning  about  such  qmciAcaoons. 
but  they  are  not  directly  available  to  users  of  programs.  The  role  of  shared  language  specifications 
is  similar  to  that  of  abstract  models  in  some  other  styles  of  specification. 

Some  important  aspects  of  the  Larch  femily  of  specification  languages  are: 

Comparability  of  specification*  We  emphasize  the  incremental  construction  of  specifications 
from  other  specifications.  The  importance  of  such  mechanisms  is  discussed  in  [Burstall 
and  Goguen  77].  Larch  has  mechanisms  for  building  upon  and  decomposing 
specifications  as  well  as  for  combining  specifications. 

Emphasis  on  presentation.  Reading  specifications  is  an  important  activity.  To  assist  in  this 
process,  we  use  composition  mechanisms  defined  as  operations  on  specifications,  rather 
than  on  theories  or  models. 

Interactive  and  integrated  with  tools.  The  Larch  languages  are  designed  for  interactive  use. 
They  are  intended  to  facilitate  the  interactive  construction  and  incremental  checking  of 
specifications.  The  decision  to  rely  heavily  on  support  tools  has  influenced  our  language 
design  in  many  ways. 
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Semantic  checking.  It  is  all  too  easy  to  write  specifications  with  suprising  implications.  We 
would  like  many  such  specifications  to  be  detectably  ill-formed.  Extensive  checking 
while  specifications  are  being  constructed  is  an  important  aspect  of  our  $>proach.  Larch 
was  designed  to  be  used  with  a  powerful  theorem  prover  for  semantic  checking  to 
supplement  the  syntactic  checks  commonly  defined  for  specification  languages.  We 
%  have  been  influenced  here  by  our  experience  with  Affirm  [Musser  80]. 

Programming  language  dependencies  localized.  We  feel  that  it  is  important  to  incorporate  many 
programming-language-dependent  features  into  our  specification  languages,  but  to 

I  isolate  this  aspect  of  specifications  as  much  as  possible.  This  prompted  us  to  design  a 

single  shared  language  that  could  be  incorporated  into  different  interface  languages  in 
a  uniform  way. 

Shared  language  based  on  equations.  The  shared  language  has  a  simple  semantic  basis  taken 
from  algebra.  Because  of  the  emphasis  on  composability,  checkability  and  interaction, 
however,  it  differs  substantially  from  the  “algebraic''  specification  languages  we  have 
used  in  the  past 

Interface  languages  based  on  predicate  calculus.  Each  interface  language  is  based  on  assertions 
written  in  typed  first-order  predicate  calculus  with  equality,  and  incorporates 
programming-language-specific  features  to  deal  with  constructs  such  as  side  effects, 
exception  handling,  and  iterators.  Equality  over  terms  is  defined  in  the  shared  language; 
this  provides  the  link  between  the  two  parts  of  a  specification. 

Status  and  Plans 

We  are  still  in  the  early  phases  of  the  Larch  project  In  addition  to  the  work  described  in  this 
report  interface  languages  for  CLU  and  Mesa  have  been  designed.  {Wing  83]  contains  a  detailed 
description  of  the  semantics  of  the  CLU  interface  language.  The  Mesa  interface  language  has  not 
been  documented,  but  we  have  used  it  in  conjunction  with  the  shared  language,  to  specify  the 
program  level  interface  to  the  Cypress  data  base  system.  This  is  the  largest  specification  we  have 
attempted. 

A  primitive  checker  for  the  Shared  Language  has  been  implemented  [Kownacki  83].  In  addition 
to  parsing  specifications,  this  program  checks  various  context  sensitive  constraints  and  provides 
mechanisms  for  “expanding”  assumptions,  importations,  and  inclusions.  This  checker  is  an  interim 
tool.  We  designed  our  specification  language  in  tandem  with  an  editing  and  viewing  tool.  Many 
language  design  decisions  were  influenced  by  the  presumption  that  specifications  would  be  produced 
and  read  interactively  using  this  tool.  A  first  design  is  complete  [Zachary  83],  but  implementation 
has  yet  to  begin. 

We  are  in  the  process  of  implementing  term  rewriting  software  [Forgaard  83),  [Lescanne  83]  that 
we  hope  will  provide  much  of  the  theorem-proving  capability  needed  for  analyzing  specifications. 
The  definition  of  the  Larch  Shared  Language  calls  for  a  number  of  checks  for  which  there  can  be 
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bo  effective  procedure.  We  have  what  we  believe  are  useful  procedures,  based  on  sufficient  or 
necessary  (but  not  both)  conditions,  fix1  some  of  these  checks,  e.g..  consistency.  We  are  working  on 
procedures  for  the  others,  e.g^  checking  constrains  clauses.  This  is  a  difficult  task.  Diagnostics  present 
a  particularly  vexing  problem:  How  should  relatively  complicated  theorem-proving  procedures  report 
pfpbkms  to  users  who  are  not  familiar  with  either  their  internal  structure  or  foe  theory  underlying 
them? 

It  is  always  difficult  to  evaluate  a  language  that  has  not  been  extensively  used.  The  Larch  Shared 
i«yiy  is  especially  hard  to  evaluate  because  it  has  been  designed  for  use  in  an  environment  that 
we  have  not  yet  built  In  addition  to  foe  specification  of  Cypress,  we  have  written  a  number  of  small 
specifications.  On  the  whole,  we  were  pleased  by  the  ease  of  constructing  these  specifications  in 
Larch,  and  with  the  specifications  themselves.  While  constructing  them,  we  uncovered  several  errors 
by  inspection:  we  are  encouraged  that  most  of  these  errors  would  have  been  detected  automatically 
by  foe  checks  called  fix’  in  the  language  definition.  It  will  be  some  time,  however,  before  we  can 
draw  any  strong  conclusions  about  the  potential  utility  of  Larch  in  software  development 


Introduction 


7 


Ail  Introduction  to  the  Larch  Shared  Language 

1.  Staple  Algebraic  Specifications 

Mott  of  the  constructs  in  the  Larch  Shared  Language  are  designed  to  assist  in  structuring 
specifications,  for  both  reading  and  writing.  The  trait  is  our  bask  module  of  specification.  Consider 
die  following  specification  for  tables  that  store  values  in  indexed  places: 

TableSpec:  trait 

introduces 

new:  -*  Table 

add:  Table,  Index,  Val  -*  Table 
#€#:  Index,  Table  -»  Bool 
eval:  Table,  Index  -►  Val 
isEmpty:  Table  -*  Bool 
size:  Table  -*  Card 

coastraias  new,  add,  €.  eval,  isEmpty,  size  so  that 
for  aO  [  ind  indl:  Index,  val:  Val,  t:  Table  ] 

evaKaddfr,  ind,  val )  ,  indl  )  =  if  ind  =  indl  then  ml  else  eval (i,  indl ) 
ind  €  new  =  false 

ind  €  add (/,  indl,  val)  =  ( ind  =  indl)  |  ( ind  €  /) 
size(new )  =  0 

size(add(/,  ind,  val))  »  if  ind  €  /  then  size(/)  else  size(r)  +  1 
isEmpty(0  =  (size(/)  =  0) 

This  example  is  similar  to  a  conventional  algebrak  specification  in  the  style  of  [Guttag  and 
Horning  80]  and  [Musser  80].  The  part  of  the  specification  following  introduces  declares  a  set  of 
operators  (function  identifiers),  each  with  its  signature  (the  sorts  of  its  domain  and  range).  These 
signatures  are  used  to  sort-check  terms  (expressions)  in  much  the  same  way  as  function  calls  are 
type-checked  in  programming  languages.  The  remainder  of  the  specification  constrains  the  operators 
by  writing  equations  that  relate  sort-correct  terms  containing  them. 

There  are  two  things  (aside  from  syntactic  amenities)  that  distinguish  this  specification  from  a 
specification  written  in  our  earlier  algebrak  specification  languages: 

A  name,  TableSpec,  is  associated  with  the  trait  itself. 

The  axioms  are  preceded  by  a  constrains  list. 

The  name  of  a  trait  is  logically  unrelated  to  any  of  the  names  appearing  within  it.  In  particular, 
we  do  not  use  sort  identifiers  to  name  units  of  specifkation.  A  trait  need  not  correspond  to  a  single 
“abstract  data  type,”  and  often  does  not 

The  constrains  list  contains  all  of  the  operators  that  the  immediately  following  axioms  are 
intended  to  constrain.  It  is  the  responsibility  of  a  specification  checker  to  ensure  that  the  specification 
conforms  to  this  intent  The  constrained  operators  will  generally  be  a  proper  subset  of  the  operators 
appearing  in  the  axioms.  In  this  example  the  constrains  list  informs  us  that  the  axioms  are  not  to 
put  any  constraints  on  the  properties  of  if  then  else,  false,  0, 1.  +.  |.  and  =,  despite  their  occurrence 


8 


The  Larch  Shared  Language 


in  the  axioms.  The  judicious  use  of  constrains  lists  is  an  important  step  in  modularizing  specifications. 

We  araociate  a  theory  with  every  trait.  A  theory  is  a  set  of  well-formed  formulas  (wff  s)  of  typed 
fint-oider  predicate  calculus  with  equations  as  atomic  formulas. 

The  theory,  call  it  Th,  associated  with  a  trait  written  in  the  Larch  Shared  language  is  defined 
hy: 

Axioms:  Each  equation,  universally  quantified  by  the  variable  declarations  of  the  containing 
constrains  clause,  is  in  Th. 

Inequation:  -(true  =  false)  is  in  Th.  All  other  inequations  in  Th  are  derivable  from  this  one 
and  die  meaning  of  = . 

First-order  predicate  calculus  with  equality:  Th  contains  the  axioms  of  conventional  typed 
first-order  predicate  calculus  with  equality  and  is  closed  under  its  rules  of  inference. 

The  equations  and  inequations  in  Th  are  derivable  from  the  presence  of  axioms  in  the  trait— never 
from  their  absence.  Th  is  deliberately  small,  because  it  is  important  to  prove  theorems  before  a 
specification  is  complete,  and  we  wanted  to  limit  the  circumstances  under  which  the  addition  of  new 
operators  and  equations  could  invalidate  previously  proved  theorems.  Had  we  chosen  to  take  the 
theory  associated  with  either  die  initial  or  final  interpretation  of  a  set  of  equations  (as  in  [ADJ  78] 
and  [Wand  79JX  this  monotonicity  property  would  have  been  lost. 

1  Getting  Richer  Theories 

While  the  relatively  small  theory  described  above  is  often  a  useful  one  to  associate  with  a  set  of 
axioms,  there  are  times  when  a  larger  theory  is  needed,  e.g.,  when  specifying  an  “abstract  data  type.” 
Generated  by  and  partitioned  by  give  different  ways  of  specifying  larger  theories. 

Section  1  does  not  include  an  induction  schema.  This  is  an  appropriate  limitation  when  the  set 
of  generators  for  a  sort  is  incomplete.  Saying  that  sort  S  is  generated  by  a  set  of  operators.  Ops, 
amerts  that  each  term  of  sort  S  is  equal  to  a  term  whose  outermost  operator  is  in  Ops.  One  might, 
for  example,  say  that  the  natural  numbers  are  generated  by  0  and  successor  and  the  integers  generated 
by  0,  successor.  and  predecessor.  Generated  by  adds  an  inductive  rule  of  inference. 

This  inductive  rule  and  die  clause  Table  generated  by  [  new,  add  ]  can  be  used  to  derive  theorems 
such  as 

Vc  Table  [  (i  =  new)  |  (3fmt  Index  [  ind  €.  r]H 
that  would  otherwise  not  be  in  the  theory. 
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Section  1  allows  equations  to  be  derived  only  by  direct  equadonal  substitution,  not  by  the 
absence  of  inequations.  This  is  an  appropriate  limitation  when  the  set  of  observers  for  a  sort  is 
incomplete.  Saying  that  sort  S  is  partitioned  by  a  set  of  operators.  Ops,  asserts  that  if  two  terms  of 
sort  S  are  unequal,  a  difference  can  be  observed  using  an  operator  in  Ops.  Therefore,  they  must  be 
equal  if  they  cannot  be  distinguished  using  any  of  the  operators  in  Ops.  This  rule  of  inference  adds 
new  equations  to  the  theory  associated  with  a  trait,  thus  reducing  the  number  of  equivalence  classes 
in  the  equality  relation. 

This  rule  and  the  clause  Table  partitioned  by  [  €,  eval  ]  can  be  used  to  derive  theorems  such  as 
add(add(r,  ind  v),  indl,  v)  =  addfadd (/,  indl ,  v),  ind  v), 
that  would  otherwise  not  be  in  the  theory. 

3.  Combining  Independent  Traits 

Our  example  contains  a  number  of  totally  unconstrained  operators,  e.g.,  false  and  + .  Such  traits 
are  not  very  useful  The  most  straightforward  thing  to  do  would  be  to  augment  the  specification  with 
additional  clauses  dealing  with  these  operators.  One  way  to  do  this  is  by  trait  importation.  We  might 
add  to  trait  TableSpec: 

imports  Cardinal  Boolean 

The  theory  associated  with  the  importing  trait  is  the  theory  associated  with  the  union  of  all  of 
the  introduces  and  constrains  clauses  of  the  trait  body  and  the  imported  traits. 

Importation  is  used  both  to  structure  specifications  to  make  them  easier  to  read  and  to  ir.  roduce 
extra  checking.  Operators  appearing  in  imported  traits  may  not  be  constrained  in  either  the  importing 
trait  or  any  other  imported  trait  This  guarantees  that  imported  traits  don’t  “interfere”  with  one 
another  in  unexpected  ways.  I.e.,  it  guarantees  that  the  theory  associated  with  a  trait  is  a  conservative 
extension  of  each  of  the  theories  associated  with  its  imported  traits.  (An  extension,  Thl,  of  a  theory, 
Th2,  is  conservative  if  and  only  if  every  wff  of  the  language  of  Th2  which  is  in  Thl  is  also  in  Th2.) 
Each  imported  trait  can,  therefore,  be  fully  understood  independently  of  the  context  into  which  it  is 
imported. 

As  a  syntactic  amenity,  trait  Boolean  is  automatically  imported  into  all  other  traits. 
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4.  CemMujug  Interacting  Traits 

While  die  modularity  imposed  by  importation  is  often  help  Ail,  it  can  sometimes  be  too  restrictive. 
It  is  often  convenient  to  combine  several  traits  dealing  with  different  aspects  of  the  Same  operator. 
This  is  common  when  specifying  something  that  is  not  easily  thought  of  as  an  abstract  data  type. 
Thut  inclusion  involves  die  same  union  of  clauses  as  trait  importation,  but  allows  the  included 
operators  to  be  further  constrained.  Consider,  for  example: 

Reflexive:  trait 

introduces  #  jel#:  T.  T  —  Bool 
constrain  .rel  so  that  for  ad  [  U  T 1 

l  jel  t  —  true 
Symmetric:  trait 

introduces  #jel#:  T,  T  -*  Bool 
constrain  .rel  so  that  for  all  [  tl,  t2:  T  ] 

it  Jel  t2  =  l2  .rel  tl 
Transitive:  trait 

introduces  #.rel#:  T.  T  -*  Bod 
constrains  .rel  so  that  for  all  [  tl,  t2,  t3:  T  ] 

(((//  .rel  tl)  A  ( t2  jel  tJ))  (tl  .rel  tS))  =  true 
Equivalence:  trait 

inchides  Reflexive,  Symmetric,  Transitive 
Equivalence  has  the  same  associated  theory  n  die  less  structured  trait 
Equivalencel:  trait 

introduces  #jel#:  T,  T  -*  Bool 
constrains  .rel  so  that  for  all  [  tl,  t2,  t3:  T  ] 

tl  jel  tl  =  true 
tl  jel  t2  -  t2  .rel  tl 

((( tl  jel  tl)  A  (t2  jel  tS))  -»  (tl  .rel  U))  =  true 
Any  legal  trait  importation  may  be  replaced  by  trait  inclusion  without  either  making  the  trait 
illegal  or  changing  the  associated  theory.  It  does  involve  the  sacrifice  of  the  checking  that  ensures 
that  the  imported  traits  may  be  understood  independently  of  the  context  in  which  they  are  used.  We 
use  importation  when  we  can  incorporate  a  theory  unchanged,  inclusion  when  we  cannot 

5.  Renaming  and  Exclusion 

The  specification  of  Equivalence  in  the  previous  section  relied  heavily  on  the  coincidental  use 
of  the  operator  jel  and  the  sort  identifier  T  in  three  separate  traits.  In  the  absence  of  such  happy 
coincidences,  renaming  can  force  names  to  coincide,  keep  them  from  coinciding,  or  simply  replace 
them  with  more  suitable  names. 
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The  phrase 
Tr  with  [  x  for  y  1 

Mods  for  the  trait  Tr  with  every  occurrence  of  y  (which  must  be .  Jrer  a  sort  or  opqpator  identifier) 
replaced  by  x.  Notice  that  if  y  is  a  sort  identifier  this  renaming  may  change  the  signatures  associated 
iqth  some  operators. 

-  Occasionally  we  wish  to  eliminate  an  operator  altogether.  The  phrase 
Tr  without  [  op  ] 

stands  for  die  trait  Tr  without  die  declaration  of  op  and  without  each  axiom,  generated  by.  and 
partitioned  by  in  which  op  appears.  We  use  without  to  remove  an  operator  either  so  that  we  can  later 
add  another  operator  with  die  same  name  and  signature  but  different  properties  or  merely  because 
it  is  superfluous  and  we  want  to  spare  readers  the  bother  of  looking  at  it 

If  TabkSpec  contains  the  generated  by  and  partitioned  by  of  section  2,  the  specification 

AmySpec:  trait 

imports  IntegerSpec 

includes  TableSpec  without  [  size ) 

with  (  defined  for  #€#.  assign  for  add,  read  for  evai. 

Array  for  Table,  Integer  for  Index  ] 

stands  for 

AmySpec:  trait 

inports  IntegerSpec 
introduces 

new:  -*  Amy 

assign:  Amy,  Integer,  Val  -*  Amy 
defined:  Integer.  Amy  -*  Bod 
read:  Amy,  Integer  -*•  Val 
isEmpty:  Amy  -*  Bool 

constrains  new,  assign,  defined,  read,  isEmpty  so  that 
Amy  generated  by  (  new,  assign  ] 

Amy  partitioned  by  [  defined,  read  ] 

for  all  ( ind  indl:  Integer,  val:  Val,  t:  Amy  ] 

read(assign(f,  ind,  vat),  ind!)  = 

if  ind  =  indl  then  val  else  read(4  indl) 
defined(rnd  new)  =  false 

defined (indl,  assign(r,  ind  val))  =  ((ind  =  indl)  |  definedO'm//,  0) 

Notice  that  in  this  specification  isEmpty  is  totally  unconstrained.  In  section  7  we  discuss  a 
checking  mechanism  that  would  call  the  lack  of  constraints  on  isEmpty  to  the  specifier’s  attention. 
This  would,  presumably,  provoke  him  either  to  add  the  axioms 

isEmpty(new)  =  true 
isEmpty(assign(f,  ind  val))  =  false 

to  his  specification,  or  to  add  isEmpty  to  the  without  clause. 

Hie  use  of  without  rather  than  some  sort  of  hiding  mechanism  (as  in  [Burstall  and  Goguen  81]) 
may  thus  involve  some  extra  work  for  the  specifier.  In  return  for  this  work,  users  of  the  specification 
are  spared  having  to  deal  with  the  "hidden”  operators,  e.g.,  in  proofs  that  use  the  specification.  This 
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k  consistent  with  our  belief  that  specifiers  should  be  encouraged  to  do  things  that  will  make  life 
eerier  for  users  of  their  specifications. 

The  definition  of  without  should  make  it  dear  that  we  are  indeed  operating  on  £e  text  of  traits 
(presentations)  rather  than  on  their  associated  theories.  Consider  adding  these  isEqtpty  axioms  to 
TpbieSpec  to  torn  another  trait,  TableSpecl.  TableSpec  and  TableSpecl  have  the  same  associated 
theories,  but 

TableSpec  without  size 
and 

TableSpecl  without  size 

have  rather  different  associated  theories — in  the  latter,  isEmpty  is  ftiQy  defined. 

A  final  point  raised  by  the  examples  of  this  section  is  the  importance  of  dwtinguishing  between 
the  history  of  a  specification  (how  it  was  constructed)  and  the  structure  presented  to  a  reader.  A 
reader  familiar  with  TableSpec  might  prefer  to  read  the  first  version  of  Array  Spec;  others  might  find 
it  detracting  to  have  to  understand  die  more  general  structure  before  understanding  AmySpec. 


We  often  construct  fairly  general  specifications  that  we  anticipate  will  later  be  specialized  in  a 
variety  of  ways.  Consider,  for  example, 

MultiSetSpec:  trait 

introduces 

{}:  -*  Multiset 

insert:  Multiset,  Bern  -*  Multiset 
delete:  Multiset,  Hem  -*  Multiset 
#€#:  Multiset,  Hem  -*  Bool 
constrains  {},  insert  delete,  €  so  that 
Multiset  generated  by  [  Q.  insert  ] 

Multiset  partitioned  by  [  delete.  €  ] 
for  all  [  m.'  Multiset,  e,  el:  Hem  ] 

*  €  {}  =  false 

e  €  insenfm,  el)  =  (e  =  el)  \  (e  €  m) 
delete({},  e)  =  {} 
delete(inseTt(m,  e),  el)  = 

if  e  »  el  then  m  else  insert(delete(m,  el),  e) 

We  might  specialize  this  to  IntMultiSet  by  renaming  Hem  to  Integer  and  including  it  in  a  trait 
in  which  operators  dealing  with  Integer  are  specified,  eg., 

IntMultiSet:  trait 

imports  IntegerSpec 

includes  MultiSetSpec  with  [  Integer  for  Hem  ] 
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The  interactions  between  MultiSetSpec  and  IntegerSpec  are  very  limited.  Nothing  in 
MultiSetSpec  places  any  constraints  on  die  meaning  of  the  operators  that  occur  in  IntegerSpec,  e.g., 
0,  +,  and  <.  Consider,  however,  extending  MultiSetSpec  to  MuldSetSpecl  by  adding  an  operator 
rangeCount 

MuldSetSpecl:  trait 

huports  MultiSetSpec,  Cardinal 
introduces 

rangeCount:  Multiset,  Bern,  Bern  -*  Integer 
#<#:  Bern,  Bern  -►  Bool 

constrains  rangeCount  so  that  for  all  [  el,  eZ  e3:  Bern,  m:  Multiset  ] 
rangeCount({},  el,  el)  =  0 
rangeCount(insert(m,  el),  el,  el)  = 

rangeCount(m,  el,  el)  +  (If  (el  <  eS)  St  (e3  <  el)  then  1  else  0) 
MuldSetSpecl  places  no  constraints  on  the  <  operator.  Suppose,  however,  that  this  is  not  what 
we  intend.  We  might  have  definite  ideas  about  the  properties  that  <  must  have  in  any  specialization, 
eg^,  that  it  should  define  a  total  ordering.  We  could  specify  such  a  restriction  by  adding  to 
MuldSetSpecl  the  assumption  (Ordered  is  defined  in  the  Handbook  section,  on  page  36): 
assumes  Ordered  with  [  Bern  for  T  ] 

In  constructing  the  theory  associated  with  MuldSetSpecl,  the  assumption  would  be  treated  as  if 
Ordered  with  [  Bern  for  T  ]  had  been  included.  This  could  be  used  to  derive  various  properties  of 
MuldSetSpecl,  e.g.,  that  rangeCount  is  monotonic  in  its  last  argument 

Whenever  the  augmented  MuldSetSpecl  is  imported  or  included  in  another  trait  however,  the 
assumption  will  have  to  be  be  discharged.  In 
IntMultiSetl:  trait 

includes  MuldSetSpecl  with  [  Integer  for  Bern  ] 
imports  IntegerSpec 

this  would  amount  to  showing  that  the  (renamed)  theory  associated  with  Ordered  is  a  subset  of  the 
theory  associated  with  IntegerSpec.  Often,  the  assumptions  of  a  trait  are  used  to  discharge  the 
assumptions  of  traits  it  imports  or  includes. 

We  have  now  looked  at  those  parts  of  the  Larch  Shared  Language  that  determine  the  theory 
associated  with  a  valid  trait  That  subset  of  the  language  contains  some  checkable  redundancy;  e.g., 
amumptions  are  checked  when  a  trait  is  included  or  imported,  and  constrains  lists  are  checked  against 
the  axioms  associated  with  them.  We  now  turn  to  a  part  of  die  language  whose  only  purpose  is  to 
introduce  checkable  redundancy,  in  the  form  of  assertions  about  the  theory  associated  with  a  trait 
There  are  two  kinds  of  consequence  assertions: 

That  the  theory  associated  with  a  trait  contains  another  theory. 

That  the  theory  associated  with  a  trait  “adequately”  defines  a  set  of  operators  in  terms  of 


14 


The  Larch  Shared  Language 


other  operator!. 

The  fint  kind  of  amotion  is  made  using  implies.  Consider,  for  example,  adding  to  the  augmented 

topics  Car  al  (ml*  Multiset,  el.  e2,  e3:  Bern] 

(e2  <  eJ)  -»  (rangeCountfm,  el,  e2)  ^  rangeCount(m,  el,  el)) 

ImpHcs  can  be  used  to  indicate  intended  consequences  of  a  specification,  both  for  checking  and 
to  incfcaee  die  reader’s  insight.  The  theory  to  be  implied  can  be  specified  using  die  foil  power  of 
die  language,  t&,  by  using  generated  by  and  partitioned  by,  or  by  referring  to  traits  defined  elsewhere. 

The  second  kind  of  assertion  is  made  using  converts  [  Ops  J.  This  asserts  that  each  term  is 
provabiy  equal  to  a  term  that  does  not  contain  operators  in  Ops.  (We  do  not  require  this  for  terms 
containing  variables  of  sorts  appearing  in  generated  by  clauses.)  Converts  is  used  to  say  that  the 
specification  adequately  defines  a  collection  of  operators. 

A  common  problem  with  axiomatic  systems  is  deciding  whether  there  are  “enough”  axioms. 
Converts  provides  a  way  of  making  a  checkable  statement  about  die  adequacy  of  a  set  of  axioms. 
Consider,  for  example,  adding  to  TableSpec: 
converts  [  isEmpty  J. 

This  says  that  each  term  containing  isEmpty,  such  as  isEmpty(new)  or  isEmpty(add(new),  ind,  val)), 
is  equal  to  another  term  that  does  not  contain  isEmpty. 

Now  consider  adding  to  TableSpec  the  stronger  assertion: 
converts  ( isEmpty,  eval  J. 

Terms  containing  subtenns  of  the  form  evaKnew,  ind)  are  not  convertible  to  terms  that  do  not  contain 
eval  so  an  error  message  of  the  form 
evaKnew,  ind)  not  convertible 

would  be  generated.  This  would  present  a  problem  if  we  did  not  wish  to  add  an  axiom  to  resolve 
this  incompleteness.  We  therefore  provide  a  mechanism  to  allow  specifiers  to  indicate  that  the 
unconvertibility  of  certain  terms  is  acceptable.  If  TableSpec  were  modi  fed  to  include 
mmpts  for  all  [  ind:  Index  ]  evaKnew,  ind) 

the  checking  associated  with  the  converts  would  now  require  that  the  theory  associated  with  TableSpec 
must  contain  either 

an  equation,  t  =  tl,  where  tl  has  no  occurrences  of  isEmpty  or  eval  or 
an  equation  t’  =  tl,  where  t’  is  a  subterm  of  t,  and  tl  is  an  instantiation  of  evaKnew,  ind). 
This  checking  ensures  that  each  term  containing  operators  in  the  converts  list  is  either  defined 
by  die  axioms  (in  terms  of  operators  not  in  the  list)  or  explicitly  exempted.  One  use  of  converts  is 
to  allow  the  specification  checker  to  notice  unintended  effects  of  without  As  suggested  in  section  6. 
the  failure  of  ArraySpec  to  folfiQ  the  converts  inherited  from  TableSpec  would  trigger  error  messages 
of  the  form: 

isEmpty(new)  not  convertible 
isEmpty(aMign(i  ind.  val))  not  convertible. 
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I.  tfHanFbr  and  EqnaUty 

fat  our  examples  we  made  use  of  tome  apparently  unconstrained  operators:  if  then  eke  and  =. 
with  a  variety  of  signatures.  In  feet,  the  appearance  of  these  operators  leads  lb  the  implicit 
incorporation  of  the  traits  IfThenEbe  and  Equality. 

Whenever  a  term  of  the  form  if  b  then  tl  dse  t2  occurs  in  a  trait  we  replace  the  mix  Ax  symbol 
if  then  else  by  die  prefix  symbol  ifThenEbe.  If  tl  and  t2  are  of  the  same  son.  Tl.  we  also  import 
the  trait  IfThenEbe  with  l  Tl  for  T  ]  into  the  enclosing  trait 

Whenever  a  term  of  the  form  tl  =  t2  occurs  in  a  trait,  if  tl  and  t2  are  of  the  same  son.  Tl.  we 
append  the  trait  Equality  with  [  Tl  for  T  ]  to  the  consequences  of  the  enclosing  trait 

Specifications  of  these  traits  are: 

IfThenEbe:  trait 

introduces  ifThenEbe:  Bool,  T.  T  —  T 
constrains  ifThenEbe  so  that  for  aO  [  r/.  i2:  T  ] 

ifThenEbe( true,  tl,  t2)  =  tl 
ifThenEbeCfebe.  tl,  tl)  =  t2 
hapliti  converts  { ifThenEbe  ] 

Equality:  trait 

hdades  Equivalence  with  [  =  for  .rel  ] 
coustrafes  ss  so  that  T  partitioned  by  1  =  J. 

9.  Some  Farther  Examples 

The  following  series  of  examples  is  adapted  from  the  Handbook  chapter.  We  include  them  here 
to  illustrate  some  ways  in  which  die  facilities  introduced  above  can  be  used.  In  reading  these 
specifications,  keep  in  mind  that  they  are  not  themselves  ends,  but  rather  means  to  write  interface 
specifications. 

Our  first  example  is  an  abstraction  of  those  data  structures  that  “contain”  elements,  e.g.,  Sec 
Bag,  Queue.  Stack.  We  have  found  it  usefol  both  as  a  starting  point  for  specifications  of  various 
kinds  of  containers,  and  as  an  assumption  for  generic  operations.  The  crucial  part  of  the  trait  is  the 
generated  by.  It  indicates  that  any  term  of  sort  C  is  equal  to  some  term  in  which  new  and  insert  are 
the  only  operators  with  range  C — even  if  this  trait  is  included  in  one  that  introduces  additional 
operators  that  return  values  of  sort  C.  This  means  that  any  theorems  proved  by  induction  over  new 
and  insert  will  remain  valid. 

Container  trait  %  Cs  contain  E's 

introduces 

new:  -*  C 
insert:  C,E-*C 

constrains  C  so  that  C  generated  by  [  new,  insert  ] 

The  next  example  incorporates  Container  as  an  assumption.  Notice  that  it  constrains  new  and 
insert  as  well  as  the  operator  it  introduces,  is  Empty.  The  converts  indicates  that  this  trait  contains 
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daw  to  adequately  specify  isEmpty.  Became  of  the  generated  by,  this  can  be  proved  by 
over  tern  of  tort  C,  mint  new  at  the  basis  and  insertfc,  r)  in  the  induction  step. 


fotredacas  iaEmpty:  C  -»  Bool 

canafnAm  isEmpty,  new,  insert  to  that  for  afi  [  c:  C,  e:  E  ] 

M3mpty(aew)  =  true 
isEmpcy(inaeTt(c.  ej)  =  false 
lapBes  ceaverts  ( isEmpty  ) 

The  neat  two  example!  aaaume  Container.  The  exempts  indicate  that  should  these  traits  be 
■dad  into  a  trait  that  claims  the  convertibility  of  next  or  rest,  that  trait  needn’t  convert  the  terms 

(new)  or  ram(aew)i 
Nett  tank 


next:  C  -»  E 

next,  insert  so  that  for  all  {  e;  E ) 
(iaeertfaew,  r))  =  e 


C  -  C 

insert  so  that  for  all  [  e:  E  ] 
^new, «))  s  new 


The  next  example  specifies  properties  common  to  various  data  structures  such  as  stacks,  queues, 
rity  queues,  sequences,  and  vectors.  It  augments  Container  by  combining  it  with  IsEmpty,  Next, 
Rem.  The  partitioned  by  indicates  that  next,  rest,  and  isEmpty  are  sufficient  to  define  equality 
r  (arms  of  sort  C.  Since  we  have  little  information  about  next  and  rest,  the  partitioned  by  does 
yet  add  much  to  the  —printed  theory. 


bEaapty,  Next,  Rem 


ceamratas  C  sa  that  C  partitioned  by  [  next,  rest,  isEmpty  ] 

The  next  example  speriatires  Enumerable  by  farther  constraining  next,  rest,  and  insert  Sufficient 
—  ate  given  to  convert  next  and  rest  The  axioms  that  convert  isEmpty  are  inherited  from  the 
Enumerable,  which  inherited  them  from  the  trait  IsEmpty. 
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PriofityQueue:  tnk 

mM  TotaKhder  with  [  E  for  T  ] 
hthfci  Enumerable 

coustraiss  next,  rest,  insert  so  that  for  aU  [  q:  C,  e:  E  ] 
nexttfnsertfo  e))  = 

if  isEmpty^)  then  e 
else  if  nextfa)  <,  e  then  nextfa)  dse  e 
restfinsertfa,  e))  = 

if  i*Empty(g)  then  new 

else  if  next(4)  ^  e  then  insert(rest(«),  e)  else  q 
tallies  converts  [  next,  rest,  isEmpty  ] 

In  a  trait,  such  as  PriorityQueue,  that  defines  an  “abstract  data  type”  there  will  generally  be  a 
distinguished  sort  (C  in  this  case)  corresponding  to  the  “type  of  interest"  of  [Guttag  75]  or  “data 
sort”  of  [BurstaD  and  Goguen  81].  In  such  traits,  it  is  usually  possible  to  partition  the  operators  whose 
range  is  die  distinguished  sort  into  “generators,”  those  operators  which  the  sort  is  generated  by.  and 
“extensions,”  which  can  be  converted  into  generators.  Operators  whose  domain  includes  the 
distinguished  sort  and  whose  range  is  some  other  sort  are  called  “observers.”  Observers  are  usually 
convertible,  and  the  sort  is  usually  partitioned  by  one  or  more  subsets  of  the  observers  and  extensions. 

The  next  example  illustrates  a  specialization  of  Container  that  does  not  satisfy  Enumerable.  It 
augments  Container  by  combining  it  with  IsEmpty  and  Cardinal,  and  introducing  two  new  operators. 
Notice  that  we  include  Container,  because  we  intend  to  constrain  operators  inherited  from  it,  but 
import  IsEmpty  and  Cardinal,  because  we  do  not  intend  to  constrain  any  operator  inherited  from 
them.  Constrains  C  is  a  shorthand  for  a  constrains  clause  listing  all  the  operators  whose  signature 
includes  C.  The  partitioned  by  indicates  that  count  alone  is  sufficient  to  distinguish  unequal  terms  of 
sort  C.  Converts  [  isEmpty.  count,  delete  ]  is  a  stronger  assertion  than  the  combination  of  an  explicit 
converts  [  count,  delete  ]  with  the  inherited  converts  [  isEmpty  ]. 

Multiset'  trait 

assumes  Equality  with  [  Elem  for  T  ] 
imports  IsEmpty,  Cardinal 
includes  Container  with  [  empty  for  new  ] 
introduces  count  Elem,  C  -*  Bool 
delete:  Elem,  C  -*  C 
constrains  C  so  that 

C  partitioned  by  [  count  ] 
for  all  ]  a  C,  el.  e2:  E  ] 

count( empty,  el)  -  0 

count(insert(c.  el),  el)  -  countfc.  el)  +  (if  el  =  e2  then  1  else  0) 
delete(empty,  el)  =  empty 
delete(insert(c,  el),  e2)  = 

if  el  =  e2  then  c  else  insert(delete(c,  el),  el) 
implies  converts  [  isEmpty,  count,  delete  ] 


EOT 
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The  next  example  specifies  a  generic  operator.  It  uses  Enumerable  as  an  assumption  to  delimit 
the  applicability  of  this  operator  to  containers  for  which  it  is  possible  to  enumerate  the  contained 
dements.  (To  understand  why  we  assume  Enumerable  rather  than  Container,  imagineglefining  extOp 
for  a  MuhiSet)  The  exempts  indictates  that  we  do  not  intend  to  folly  define  the  meaning  of  applying 
egtOp  to  containers  of  unequal  size.  Notice  that  elemOp  is  totally  unconstrained  in  this  trait  This 
prevents  us  from  having  many  interesting  implications  to  state  at  this  stage. 

PairwiseExtension:  trait 

aasames  Enumerable 
introduces 

demOp:  E,  E  -*  E 
extOp:  C,  C  -*■  C 

extOp  so  that  for  all  (  cl,  c2:  C,  el,  e2:  E ) 
extOp(new,  new)  =  new 

extOp(insert(c7,  el),  insert(c2,  el))  -  insert(extOp(c/,  cl),  elemOp {el,  el)) 

implies  converts  ( extOp  ] 
exempts  for  afi  (c:C,e.E] 
extOp(new,  insertfe,  e)\ 
extOp(insert(c  e\  new) 

Now  we  specialize  PairwiseExtension  by  binding  elemOp  to  +  over  Cardinals: 

PairwisePlus:  trait 

amames  Enumerable 
(■ports  Cardinal 

inchi  iei  PairwiseExtension  with  (  #  +  #  for  elemOp,  *  +  #  for  extOp.  Card  for  E  ] 
implies  Commutative  with  (  #  +  #  for  O,  C  for  T 1 

The  validity  of  the  implication  that  +  for  sort  C  is  commutative  stems  from  the  replacement  of 
demOp  by  +  for  sort  Card,  whose  constraints  (in  trait  Cardinal)  imply  its  commutativity. 
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A.  Structure  of  Manual 


la  section  1  we  present  a  grammar  for  the  kernel  subset  of  the  Larch  Shared  Language. 

In  section  2  we  define  the  context  sensitive  checking  and  the  theory  associated  with  each 
specification  written  in  the  kernel  subset 

In  section  3  we  extend  the  kernel  subset  by  introducing  mechanisms  for  specifying  intended 
consequences  of  a  specification  written  in  the  kernel  subset 

In  sections  4*10  we  define  successive  extensions  of  the  language.  We  modify  the  grammar  to 
introduce  additional  aspects  of  the  language  and  describe  any  additional  context  sensitive  checking 
required.  We  also  provide  a  translation  from  the  newly  extended  language  to  the  previously  defined 
subset  The  result  of  this  translation  is  subjected  to  all  foe  applicable  checking.  The  theory  associated 
with  any  specification  written  in  the  foil  language  is  foe  same  as  the  theory  associated  with  its 
translation. 

Section  11  describes  additional  checks,  defined  in  terms  of  the  theories  associated  with  traits, 
that  are  associated  with  various  language  features.  To  be  legal,  a  specification  and  f**  of  foe  parts 
(him  which  it  is  built  must  satisfy  these  checks  as  well  as  foe  context  sensitive  checks  described 
earlier. 

Finally,  section  12  collects  foe  reference  grammar  for  foe  entire  language. 
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1.  load  Syntax 

/./.  Syntactic  conventions 

1“ 

{«> 

€ * 

«*. 

e* 

alpha 

alpha 

V) 

(e) 

/  JL  Grammar 

trait  ::=  traitld  :  trait  traitBody 

traitBody  ::=  aimptaTrait 

aimplaTrait  ::=  {opPart}  propPart* 

opPart  ::=  introduces  opDcl* 

opDcl  ::=  op/d  :  signature 

signature  ::=  domain  ~*  range 

domain  ::=  aortld*, 

range  ::=  aortld 

propPart  ::=  iwiti  props 

props  ::  = generators *  partitions *  axioms* 

generators  ::=  aortld  pwntiJ  bylist*, 

partitions  ::=  aortld  partitioned  bylist*, 

tiytiat  ::s  |jr  [ aortedOp*,  ] 

aortedOp  ::=  opDcl 

axioms  ::=  for  afl  ( varDcl*,  ]  equation* 

varDcl  ::=  varkf*, :  aortld 

equation  ::=  term  =  farm 

farm  aortedOp  {*(  form*.  *)}  |  var/d 

opid  alphanumeric*  \opForm 

opForm  ::={#}  opSym  (  #  opSym  )*  {  #  } 

opSym  apecialChar*  | .alphanumeric* 

traitld  ::  =  alphanumeric  * 

aortld  ::=  alphanumeric* 

vartd  ::=  alphanumeric* 

Comments  start  with  %  and  terminate  with  end  of  line.  They  may  appear  after 


alternative  separator 
e  is  optional 
zero  or  more  e’s 

zero  or  more  e’s,  separated  by  commas 

one  or  more  e’s 

alpha  is  a  nonterminal  symbol 

alpha  is  a  terminal  symbol 

parentheses  as  terminal  symbols 

parentheses  for  grouping  syntactic  expressions 
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2.  Staple  Traits 

11.  Context  sensitive  cheeking 
affhpiaTrah: 

*  The  sets  of  varkfs,  aortirfs  and  oplcf$  appearing  in  a  trait  must  be  disjoint 
Every  aortld  appearing  anywhere  in  a  aimpieTrait  must  appear  in  its  opPart. 

Every  aortadOp  appearing  anywhere  in  a  aimpieTrait  must  appear  in  its  opPart. 

opOck 

Each  opform  must  have  die  same  number  of  #’s  as  the  number  of  occurrences  of  aortld’s  in 
die  domain. 

ganaratora: 

The  range  of  each  aortadOp  must  be  the  aortkt  of  the  ganaratora. 

At  least  one  aortadOp  in  each  bylfat  must  have  a  domain  in  which  the  aortld  of  the  ganaratora 
does  not  occur. 

partitiona: 

The  domain  of  each  aortadOp  must  include  the  aortld  of  die  partitiona. 

The  range  of  at  least  one  aortadOp  in  each  byiiat  must  be  different  from  die  aortld  of  the 
partitiona. 

axioms: 

Each  varid  used  in  a  term  must  appear  in  exacdy  one  varDci. 

No  varid  may  occur  more  than  once  in  (  varDci *,  J. 

aquation: 

The  sorts  of  both  farm’s  must  be  the  same,  where 
The  sort  of  a  term  of  the  form  aortadOp  {  ’( term*,  T  }  is  the  range  of  the  aortadOp. 

The  soft  of  a  term  of  the  form  varid  is  the  aortld  of  the  varDci  in  which  the  varid  is  declared. 

term: 

In  aortadOp  { t  term*,  *)  }  the  domain  of  the  aortadOp  must  be  the  sequence  of  the  sons  of 
the  forms  in  form*, . 
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22  Associated  theory 

We  associate  a  theory  with  each  trait.  This  section  defines  the  theory  associated  with  a 
sknpteTrait. 

A  theory  is  a  subset  of  the  language: 
wff  ::=  term  =  term 

|  "propositional  formula" 
j  "first  order  quantified  (with  sorts)  formula” 

We  adopt  the  conventional  meanings  of  the  equality  symbol  (=),  the  propositional  connectives 
(A,  I.  -X  and  the  quantifiers  (V  and  3). 

The  subset  of  wtt  that  is  the  theory,  call  it  Th,  associated  with  a  simpteTrait  is  defined  by: 
Axioms:  Each  aquation,  universally  quantified  by  the  varDct s  of  its  containing  axioms,  is  in 
Th. 

Inequation:  -(true:-* Bool  =  false: -♦Bool)  is  in  Th. 

First  order  predicate  calculus  with  equality:  Th  contains  the  axioms  of  conventional  typed 
first-order  predicate  calculus  with  equality  and  is  closed  under  its  rules  of  inference. 

Induction:  If  the  trait  has  a  generators  with  sortld  S  and  a  bylist  by  [opi . opj,  and  P(s) 

is  a  wflf  with  a  free  variable,  s,  of  sort  S,  Th  contains  the  wfF 
Vls:SlP(s) 

if  for  each  opi  in  (opi . opj 

Qi  P(opj(xi . xj)  is  in  Th,  where 

k  is  the  arity  of  opi, 

die  Xj’s  are  variables  that  do  not  appear  free  in  P,  and 
Qi  is  the  conjunction  of  P(xj),  for  each  j  such  that  the  j4  argument  of  opt 
is  of  son  S. 

Reduction :  If  the  trait  has  a  partitions  with  sortld  S  and  a  bylist  by  [opi, ....  opj,  Th  contains 
the  wff 

V[si,  S2:  SJ  (Q  ■*  si  =  S2) 

where  Q  is  foe  conjunction,  for  each  opj  in  [opi . opj  and  each  j  such  that  the  j* 

argument  of  op;  is  of  sort  S,  of 

V(*i:  Si, ... ,  xk:  SJ  (Subst(opi,  j,  tj  =  Subst(opi,  j,  tj),  where 
Si, . . .,  Sk  is  the  domain  of  opi,  and 
Subst(op,  j,  t)  is  op(xi . xj  with  t  substituted  for  Xj. 
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3.  Consequences  and  Exemptions 


Exempts  and  consequences  affect  only  the  checking  (see  section  11.5)  and  do  not  affect  the 
theory.  We  add  to  the  grammar  the  productions: 


tratt 

consequences 

conseqProps 

converts 

conversion 

exempts 

exemptTerms 


=  traitld  :  trait  traitBody  { consequences }  { exempts } 
=  implies  conseqProps  { converts } 

=  props 

-  converts  conversion *, 

=  I  sortedOp *,  ] 

«  exempts  exemptTerms * 

=  {  for  all  I  varDcl *,  I  }  term*. 


3.1.  Context  sensitive  checking 


conseqProps: 

If  die  props  of  die  conseqProps  is  appended  to  the  propPart  of  the  containing  trait,  the 
resulting  trait  must  satisfy  the  checks  of  section  2. 


exempts: 

Each  term  must  satisfy  the  checks  of  section  2.1. 


4.  Constrains  Clauses 

Constrains  clauses  aflect  only  the  checking  (see  section  11.4).  not  the  theory.  We  add  to  the 
grammar  the  productions: 

propPart  ::=  (  asserts  |  constrains  )  props 

constrains  constrains  (  sortld  |  sortedOp*, )  so  that 


4.1.  Translation 
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5.  IapBdt  Signatures  and  Partial  OpFonns 

In  die  kernel  language  each  sortedOp  is  an  opDct.  Here  we  relax  this  restriction  to  allow 
omitted  and  partial  signatures  and  omitted  #’s.  We  add  to  the  grammar  the  production: 
sOrtedOp  ::  =  opld  {  -*  range  } 

5:1.  Context  sensitive  checking 

There  must  be  a  unique  mapping  from  occurrences  of  aortedOp's  to  opDcfs  of  the  traitBody 
such  that  the  translation  described  in  section  5.2.  produces  a  legal  traitBody  and  for  each  sortedOp , 
opDcl  pair 

The  opltfs  match,  Le., 

They  are  the  same,  or 

They  are  both  opForms  and  the  one  in  the  sortedOp  is  the  same  as  the  one  in  the 
opDcl  with  all  #’s  removed. 

If  the  sortedOp  includes  -»  range,  it  is  the  same  as  the  range  of  the  opDcl. 

5.1  Translation 

The  checking  ensures  that  each  occurrence  of  a  sortedOp  corresponds  to  a  unique  opDcl.  The 
translation  is  simply  to  replace  it  by  that  opDcl. 


6.  Mixfix  Operators 

In  the  language  presented  thus  far,  all  operators  are  treated  as  either  nullary  or  prefix.  Here  we 
relax  that  restriction.  We  replace  the  grammar  for  term  by: 
term  ::=  secondary  |  if  secondary  then  secondary  else  term 

secondary  ::=  {  opSym  }  primary  (  opSym  primary  )•  {  opSym  } 
primary  ::=  sortedOp  {  ’(  term*,  ’)  }  |  varld  |  ’(  term  ') 

6.1.  Translation 

equation: 

It  is  necessary  to  resolve  the  grammatical  ambiguity  between  the  =  connective  in  equations 
and  the  =  opSym.  In  any  equation  the  first  occurrence  of  =  that  is  not  bracketed  by  parentheses 
or  within  an  if  then  else  is  the  equation  connective,  the  remainder  are  opSyms.  Parentheses  can  be 
used  to  enforce  any  desired  parsing. 
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term: 

Translate  each  term  of  the  form  if  b  then  4  else  t2  into  a  term  of  the  form  LfThenElse(b,  ti,  t2>. 
secondary: 

Translate  each  secondary  containing  opSym’s  into  a  primary  of  the  form  opld  ’(  term*,  ’), 
where 

opld  is  derived  by  replacing  each  primary  in  the  secondary  by  #. 
term*,  is  the  sequence  of  primary's. 

primary: 

After  the  previous  translations  have  been  performed,  remove  the  outer  parentheses  from 
primary’s  of  the  form  ’(  term  *). 

7.  Boolean  Terns  as  Equations 

It  is  convenient  to  use  terms  of  sort  Bool  as  axioms.  We  add  to  the  grammar  the  production: 
equation  ::=  term 

7.1.  Context  sensitive  checking 
The  term  must  be  of  sort  Bool. 

7.2.  Translation 


Replace  the  term  by  die  equation 
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S.  External  References 

We  add  to  die  kernel  grammar  the  productions: 
traltBody  ::  =  externals  slmpleTrait 

externals  ::  =  { assumes }  {imports}  { includes } 

assumes  ::  =  assumes  trait  Ref*, 

imports  ::  =  imports  traltRef *, 

includes  ::  =  includes  trait  Ref*, 

traltRef  ::=  trait  Id 

conseqProps  ::=  traitRef*,  props 

8.1.  Context  sensitive  checking 
externals: 

Recursive  externals  are  not  permitted;  i.e.,  the  traitld  of  the  containing  trait  may  not  appear  in 
an  externals,  nor  in  any  partial  translation  of  a  traitRef  in  its  externals. 

8.2.  Translation 

The  translation  of  a  trait  is  derived  bottom-up;  i.e.,  before  a  trait  with  traitRef s  is  translated, 
each  of  its  traitRef*  is  replaced  by  the  translation  of  the  trait  labeled  by  that  traitRef  s  traitld.  Let 
T  be  a  trait  whose  simpleTrait  is  S  and  let  E  consist  of  the  translations  of  the  traitRef  s  in  Ts 
externals.  The  translation  of  T  consists  of: 

An  opPart  containing  S’s  opDds  and  E’s  opDds, 

A  propPart*  containing  S's  propPart' s  and  E’s  propParf  s. 

An  exempts  containing  Ts  exemptTerms  and  E’s  exemptTerms,  and 
A  consequences  containing  the  props  of 
Ts  conseqProps, 

the  propPart*  of  the  translations  of  the  traitRef  s  in  Ts  conseqProps,  and 
E’s  consequences. 
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f.  Modifications 

We  add  to  the  grammar  the  productions: 
traitRet  ::  =  traitld  {ax elusion}  { renaming } 

exclusion  ::  =  without  (  oldOp *,  ] 

renaming  ::  =  with  [  (  sortRanama  |  opRename  )*, ) 

sortRename  ::  =  sortld  for  oldSort 

oldSort  ::  =  sortld 

opRanama  ::=  opld  for  oldOp 
oldOp  ::=  sortadOp 

9.1.  Context  sensitive  cheeking 

traitRet: 

No  sortadOp  may  occur  more  than  once  as  an  oldOp. 

No  sortld  may  occur  more  than  once  as  an  oldSort. 

Each  oldSort  must  appear  in  an  opDcl  in  the  translation  of  the  trait  labeled  by  the  traitld. 
There  must  be  a  unique  mapping  from  oldOp' s  to  opDcfs  of  the  translation  of  the  trait  labeled 
by  die  traitld.  such  that  for  each  oldOp,  opDcl  pair: 

The  opltfs  match  (see  section  S.l). 

If  the  oldOp  includes  domain,  it  is  the  same  as  the  domain  of  the  opDcl. 

If  the  oldOp  includes  -*  range,  it  is  the  same  as  the  range  of  the  opDcl. 

9.1  Translation 

The  translation  of  the  trait  labeled  by  the  traitld  of  the  traitRef  is  modified  by  applying  first 
the  exclusion,  then  the  opRename' s,  and  finally  the  sortRename's: 

For  each  oldOp  in  the  exclusion,  delete  each  bylist,  equation,  and  term  containing  the 
opDcl  to  which  it  maps  and  then  delete  all  remaining  occurrences  of  that  opDcl. 
Then,  simultaneously,  for  each  opRename,  replace  the  opld  part  of  each  occurrence  of  the 
opDcl  to  which  the  oldOp  maps  by  the  opld  of  the  opRename. 

Finally,  simultaneously,  for  each  sortRename,  replace  each  occurrence  of  its  oldSort  by  its 
sortld. 
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18  Implicit  Incorporation  of  Boolean,  IfThenEbe,  and  Equality 

Three  traits,  Boolean,  IfThenEbe,  and  Equality,  are  implicitly  incorporated  into  various  other 
traits  to  assure  uniform  meanings  Ax’  the  operators  they  constrain. 

19.1.  Translation 

Append  the  trnitRef  Boolean  to  the  imports  of  each  trait  except  Boolean. 

Append  die  traitRet  IfThenEbe  with  [  T1  for  T  ]  to  the  imports  of  each  trait  containing  a  term 
of  the  form  if  b  then  ti  ebe  t2  in  which  ti  and  t2  have  the  same  sort,  Tl. 

Append  the  traitRet  Equality  with  |  Tl  for  T  ]  to  the  traitRet*  of  the  cortseqProps  of  each 
trait  (except  Equality)  containing  a  term  of  the  form  tj  =  t2  in  which  ti  and  t2  have  the  same  sort. 
TL 

IOlI  Built-in  trails 


Boolean:  trait 


true:  -*  Bod 
false:  -*  Bool 
Bod  -*  Bool 

#£#:  Bod,  Bod  -*  Bool 
#|#:  Bod.  Bod  -♦  Bool 
Bool,  Bool  -*  Bool 
#  .equal#:  Bod,  Bod  -*■  Bool 
Bod  generated  by  ( true,  false  ] 
for  all  [  6:  Bod  ] 

-true  =  false 
-false  s  true 
(true  St  b)  =  b 
(false  St  b)  =  false 
(true  |  b)  =  true 
(fhbe  |  b)  =  b 
(true  ^  b)  -  b 
(false  ^  b)  -  true 
(true  .equal  b)  =  b 
(false  .equal  6)  =  ~b 
i  converts  [  ~.  A,  I,  .equal  ] 


IfThenEbe:  trait 


ices  ifThenEbe:  Bod,  T,  T  -»  T 
far  all  ( tl,  t2:  T ) 

ifThenEbe(true,  tl,  t2)  -  tl 
ifThenEbe(fabe,  tl,  i2)  =  t2 
i  converts  [  ifThenEbe  ] 


r 
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Equality:  Ink 

fatrodnces  #  =  #:  T.  T  —  Bool 
averts  T  urtMwd  by  I  =  1 
fcralU**:T] 

(jc=x) 

*  (y=x) 


1L  Sfitlc  Checking 

In  addition  to  die  syntactic  constraints  specified  above,  we  require  that  each  trait  be  logically 
consistent,  discharge  the  assumptions  of  the  traits  it  is  built  from,  be  a  conservative  extension  of  its 
imports,  be  properly  constraining,  and  imply  its  consequences. 

ILL  Consistency 

A  traitBody  is  consistent  if  its  associated  theory  does  not  contain  the  equation 
true:-* Bod  *  false:-* Bool 

1 1.1  Assumptions 

Let  A(T)  be  all  of  the  assumes  of  the  traits  imported  or  included  in  T.  and  R(T)  be  the  result 
of  translating  T  after  removing  these  assumes.  AfT)  is  discharged  by  T  if  the  theory  associated  with 
the  translation  of  each  traitRef  of  A(T)  is  a  subset  of  the  theory  associated  with  R(T). 

ILL  Imports 

The  theory  associated  with  a  trait  must  be  a  conservative  extension  of  the  theory  associated  with 
the  translation  of  each  traitRef  in  its  imports ;  i.e.,  if  trait  T1  imports  T2  and  W  is  a  wff  of  T2.  W 
is  in  the  theory  associated  with  T1  if  and  only  if  it  is  in  the  theory  associated  with  T2. 

11.4.  Constraints 

A  propPart  is  properly-constraining  if  it  implies  properties  of  only  the  operators  in  its  constrains. 
The  occurrence  of  a  sortld  in  a  constrains  stands  for  the  list  of  all  sortedOp' s  in  the  containing 
trait's  opPart  whose  signatures  include  that  sortld. 

Let  T  be  a  trait  and  P  be  the  propPart  constrains  sortedOp *,  so  that  props.  P  is 
properiy*constraining  in  the  trait  consisting  of  T  plus  P  if  and  only  if  each  wff  in  the  theory  associated 
with  T  plus  P  is  also  in  the  theory  associated  with  T  or  else  contains  ops  in  sortedOp*. 

Note  that,  since  the  translation  of  a  traitRef  converts  constrains  to  asserts,  this  check  is  performed 
only  on  traits  in  which  constrains  appears  explicitly. 
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/ 1.5.  Consequences 

A  trait  implies  its  consequences  if  the  theory  associated  with  its  conseqProps  is  a  subset  of 
the  theory  associated  with  the  trait  and  the  [  sortedOp *,  ]  in  each  converts  is  convertible. 
Convertibility  is  defined  using  the  theory  and  exempts  of  a  trait. 

conseqProps: 

The  theory  associated  with  conseqProps  must  be  a  subset  of  the  theory  of  the  trait  in  which 
the  consequences  appears.  The  theory  associated  with  a  conseqProps  is  the  theory  associated  with 
the  traitbody: 

includes  traitRef *,  opPart  asserts  props 

where  traitRef *,  and  props  form  the  conseqProps,  and  opPart  is  the  opPart  of  the  trait  in  which 
the  consequences  appears. 

Note  that  an  exclusion,  but  not  a  renaming,  can  invalidate  a  consequence  that  has  been  locally 
checked. 

conversion: 

Let  C  be  a  conversion.  For  each  term,  t,  that  contains  no  variables  of  any  sort  appearing  in  a 
generators  in  the  containing  trait,  the  theory  of  the  containing  trait  must  either 
contain  an  equation  t  =  u, 

where  u  contains  no  sortedOp  appearing  in  C’s  sortedOp *,  or 
contain  an  equation  t’  =  u, 

where  t’  is  a  subterm  of  t,  and  u  is  an  instantiation  of  a  term  appearing  in  an  exempts 
of  the  containing  trait 
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trait 

traitBody 

externals 

assumes 

imports 

includes 

traitRet 

exclusion 

renaming 

sortRename 

oldSort 

opRename 

oktOp 

sortedOp 

simpleTrait 

opPart 

opDci 

signature 

domain 

range 

propPart 

constrains 

props 

generators 

partitions 

bylist 

axioms 

varDcl 

equation 

term 

secondary 

primary 

opld 

opForm 

opSym 

traitld 

sortld 

varld 

consequences 

conseqProps 

converts 

conversion 

exempts 

exemptTerms 


::=  traitld  :  trait  traitBody  { consequences }  { exempts } 

::=  externals  simpleTrait 

::  =  {assumes}  { imports }  { includes } 

:;=  ammnee  traitRet*, 

::=  imports  traitRet *, 

::=  includes  traitRet*, 

::  =  traitld  { exclusion }  { renaming } 

::=  without  [  oldOp*,  ] 

::=  with  [  (  sortRename  \  opRename  )*,  ] 

::=  sortld  for  oldSort 
::=  sortld 
::=  opld  for  oldOp 
::=  sortedOp 

::  =  opDci  |  opld  {  -*  range  } 

::=  {opPart}  propPart* 

::  =  introduces  opDci* 

::  =  opld  :  signature 
domain  -*  range 
sortld*, 

::=  sortld 

(  asserts  |  constrains  )  props 

::  =  constrains  (  sortld  |  sortedOp*, )  so  that 
::  =  generators*  partitions*  axioms* 

::  =  sortld  generated  by  list*, 

::  =  sortld  partitioned  by  list*, 

::  =  by  [  sortedOp*,  J 

::  =  for  all  (  varDcl*,  I  equation* 

::=  varld*, :  sortld 

::=  term  {  ■  term  } 

::=  secondary  |  if  secondary  then  secondary  else  term 
::=  {  opSym  }  primary  (  opSym  primary  )*  {  opSym  } 
::=  sortedOp  {  ’(  term*,  ’)  }  |  varld  |  ’(  term  ’) 

::=  alphanumeric  *  |  opForm 
::={#}  opSym  (  #  opSym  )*  {  #  } 

::=  specialChar  *  \ .  alphanumeric  + 

::  =  alphanumeric  + 

::  =  alphanumeric * 

::  =  alphanumeric  * 

::=  implies  conseqProps  { converts } 

::  =  traitRet*,  props 
::  =  converts  conversion*, 

::  =  I  sortedOp*,  ] 

::=  exempts  exemptTerms* 

::=  {  for  all  (  varDcl*,  |  }  term*. 
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Basic  properties  of  single  operators,  including  binary  relations 

Associative,  Commutative,  Idempotent,  Relation,  TotalRelation,  Reflexive,  Ineflexive, 
Transitive,  ReflexiveTransitive.  Symmetric,  Antisymmetric,  Equivalence 

Ordering  relations 

PartialOrder,  TotalOrder,  Order  Equivalence,  OrderEquality,  PartialOrderWithEquality, 
TotalOrderWithEquality,  DerivedOrders,  Partial!  yOrdered,  Ordered 

Group  theory 

Leftldentity,  Rightldentity,  Identity,  Leftlnverse,  Rightlnverse,  Inverse,  Abelian,  Semigroup, 
Monoid,  Group,  AbelianSemigroup,  AbelianMonoid,  AbelianGroup,  Distributive 

Simple  numeric  types 

Ordinal,  Cardinal,  Cardinal 

Simple  data  structures 

Pair,  Triple,  FiniteMapping 

Container  properties 

Container,  Singleton,  IsEmpty,  Size.  AdditiveSize,  Join,  ElementEquality,  Member, 
ElemCount,  Delete,  Containment,  Next,  Rest,  Remainder,  Index 

Container  classes 

SetBasics,  Bag  Basics,  CollectionExtensions,  Setlntersection,  Set,  Bag,  Enumerable, 
InsertionOrdered,  Stack,  Queue,  Dequeue,  Sequence,  Subsequence,  String,  PriorityQueue 

Generic  operators  on  containers 


CoeiceContainer,  Reduce,  SomePass,  AllPass,  Sift,  Pairwise  Ex  tension,  Pointwise  Image 
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Nonlinear  structures 

BinaryTree,  BasicGraph,  Connectivity.  Graph 
Rings,  fields  and  numbers 

Ring,  RingWithUnit,  Infix  Inverse,  Integer.  Field,  Rational 
Lattices 

ExtremalBound,  Semilattice,  I  -«rtw 
Enumerated  data  types 

Enumerated,  Rainbow,  Character 
Display  traits 

Coordinate,  Illumination,  Boundary,  Transform,  Displayable,  Picture.  Contents,  Component, 
ComponentCoercion,  View,  Display 
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PicCkc 

This  collection  of  traits  is  a  companion  to  the  Larch  Shared  Language  Reference  Manual.  We 
hope  that  k  will  serve  three  distinct  purposes: 

Provide  a  set  of  components  that  can  be  directly  incorporated  into  other  specifications. 
Provide  a  set  of  models  upon  which  other  specifications  can  be  based,  and 
Help  people  to  better  understand  the  Larch  Shared  Language  by  providing  a  set  of  illustrative 
examples. 

In  line  with  our  first  goal,  we  have  tried  to  isolate  the  "smallest  useful  increments"  of  specification 
that  it  might  be  reasonable  to  use  in  other  specifications.  In  particular,  we  have  tried  to  provide  traits 
that  will  make  it  convenient  to  specify  the  weak  assumptions  that  characterize  many  of  the  more 
widely  applicable  specifications.  This  is  particularly  evident  in  the  sections  titled  "Container 
properties"  and  Container  classes."  The  traits  in  these  sections  are  smaller  and  more  numerous  than 
is  typical  in  "from  scratch"  specifications.  This  sometimes  leads  to  a  somewhat  overstructured 
appearance. 

In  line  with  our  second  goal,  in  addition  to  traits  that  we  expect  to  be  directly  incorporated  in 
specifications,  we  have  included  a  number  of  traits  intended  primarily  as  patterns.  The  section  titled 
"Generic  operators  on  containers”  contains  several  such  traits.  Because  of  the  arity  of  the  operators, 
it  will  frequently  be  awkward  to  incorporate  these  traits. 

In  line  with  our  third  goal  we  have  stressed  familiar  examples.  Since  they  describe  well-understood 
mathematical  entities,  many  of  the  traits,  e.g..  Integer,  are  atypically  complete.  In  general  we  expect 
most  specifications  to  supply  constraints,  rather  than  complete  definitions.  The  section  on  Display 
traits  is  more  typical  in  this  respect. 

The  support  tools  envisioned  for  Larch  are  not  yet  available.  Transcriptions  of  traits  in  this 
chapter  have  been  mechanically  checked  for  some  properties;  some  errors  may  not  have  been  detected 
and  some  transcription  errors  may  have  crept  in.  They  should  be  given  the  same  sort  of  credence  as 
careftilly  written  programs  that  have  not  been  checked  by  a  compiler. 

Comments  on  the  clarity  of  these  specifications  and  on  their  "correctness”  (relative  to  generally 
accepted  definitions  of  the  names  used)  are  welcome.  We  also  solicit  contributions  of  further  widely 
usefiil  traits— either  accompanied  by  specifications,  or  as  challenges  to  specifiers. 


If  a  generic  trait  constrains  only  one  interesting  sort,  the  identifier  T  is  used  to  denote  it 
If  a  trait  constrains  a  "containing”  sort  and  an  "element”  sort,  the  identifiers  C  and  E  are  used. 
If  a  trait  constrains  a  single  binary  operation,  the  infix  symbol  JkO#  is  used. 

If  a  trait  constrains  a  single  binary  relation,  the  infix  identifier  #®  #  is  used. 

If  there  would  be  no  information  in  a  constrains  (e.g„  because  there  is  only  one  operator), 
amerts  is  used. 
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Basic  Properties  of  Single  Operators,  Including  Binary  Relations 

Associative:  trait 

introduces  #0#:  T,  T  -♦  T 

asserts  for  all  I  x,  y,  z:  T  ]  (x  O  y)  O  z  -  x  O  (y  O  z) 

Commutative:  trait 

introduces  #0#:  T,  T  -*  Range 

asserts  for  all  {  x,  .y;  T  ]  x  O  y  =  y  O  x 

Idempotenf  trait 

introduces  op:  T  -•  T 

asserts  for  all  (  x:  T 1  op(op(x))  =  op(x) 

Relation:  trait 

introduces  #®#:  T,  T  Bool 
TotalRelation:  trait 

includes  Relation 

asserts  for  all  I  x,  y:  T  ]  (x  ®  y)  |  (y  ®  x) 

Reflexive:  trait 

includes  Relation 

asserts  for  aU  [  x:  T  J  x  9  x 

Irrefkxive:  trait 

includes  Relation 

asserts  for  aO  [  x:  T  J  ~(x  9  x) 

Transitive:  trait 

includes  Relation 

asserts  for  all  [  x,  y,  z:  T  ]  ((x  ®  y)  &  (y  ®  z))  »*(x®  z) 

ReflexiveTransitive:  trait 

includes  Reflexive,  Transitive 
Symmetric:  trait 

includes  Relation 

asserts  for  all  (  x,  y:  T  J  (x  ®  y)  =  (y  ®  x) 

implies  Commutative  with  [  9  for  O,  Bool  for  Range  ] 

Antisymmetric:  trait 
includes  Relation 

asserts  for  all  [  x,  y:  T  ]  ~((x  ®  y)  A  (y  9  x)) 

implies  Irreflexive 

Equivalence:  trait 

includes  ReflexiveTransitive  with  [  .eq  for  ®  ], 

Symmetric  with  [  .eq  for  9  ] 
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Offering  Relations 

PartialOrder:  trait 

imports  ReflexiveTransitive  with  [  <£  for  ®  ] 

TotalOrder:  trait 

indnfes  PartialOrder,  TotalReladon  with  [  <  for  ®  ] 

OrderEqui valence :  trait 

««nin#«  PartialOrder 
introduces  #.eq  #:  T.  T  -*  Bool 

constrains  .eq  so  that  for  all  [  x,  y:  T  ]  (x  .eq  y)  =  (x  <  y)  &  O'  <  *) 
implies  Equivalence 
converts  [  .eq  ] 

OrderEquality:  trait 

assumes  PartialOrder 

indnfes  OrderEquivalence  with  [  =  for  .eq  ],  Equality 
PartialOrderWithEquality:  trait 

includes  PartialOrder,  OrderEquality 
T otalOrder W ithEquality :  trait 

includes  TotalOrder,  OrderEquality 
DerivedOrders:  trait 

assumes  PartialOrder 
introduces 

*  <#:  T.  T  —  Bod 
#£#:  T  T  —  Bod 
#>#:  T,  T  -*  Bod 

constrains  <  so  that  for  all  (  x,  y:  T  J  (x  <  y)  =  ((jr  <>  y)  6l  {~{y  ^  x))) 

constrains  ^  so  that  for  all  [  x,  y:  T  j  (x  >  y)  -  {y  x) 

constrains  >  so  that  for  all  [  x,  y:  T  j  (x  >  y)  =  (y  <  x) 

implies  Transitive  with  (  <  for  ®  ], 

Transitive  with  [  >  for  ®  ], 

Antisymmetric  with  [  <  fo'  ®  J, 

Antisymmetric  with  [  >  for  ®  j, 

PartialOrder  with  [  j>  for  £  ] 
converts  [  <,  >  ] 

PartiallyOrdered:  trait 

imports  PartialOrderWithEquality 
includes  DerivedOrders 

implies  PartialOrderWithEquality  with  [  >  for  <  ] 

Ordered:  trait 

imports  T otalOrderW ithEquality 
includes  DerivedOrders 

implies  PartiallyOrdered,  TotalOrderWithEquality  with  (  >  for  <  ] 


rTT  -  '  V  C" 1  'C 
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Group  Theory 


unit  O  x  =  x 


x  O  unit  =  x 


inv(jc)  O  x  =  unit 


jr  O  inv(jr)  =  unit 


Leftldentity:  trait 

introduces 

#0#:  T,  T  -+  T 
unit:  -»  T 

asserts  for  all  [  x:  T  ] 

Rightldentity:  trait 

introduces 

#Otf:  T,  T  -*  T 
unit:  -*  T 

asserts  for  all  [  x:  T  ] 

Identity:  trait  includes  Leftldentity,  Rightldentity 
Leftlnverse:  trait 

assumes  Leftldentity 
introduces  inv:  T  — ►  T 
asserts  for  all  [  x:  T  J 

Rightlnverse:  trait 

assumes  Rightldentity 
introduces  inv:  T  -*  T 
asserts  for  all  [  x:  T  ] 

Inverse:  trait 

assumes  Identity 

includes  Leftlnverse,  Rightlnverse 
Abelian:  trait  imports  Commutative  with  [  T  for  Range  ] 
Semigroup:  trait  includes  Associative,  Equality 
Monoid:  trait  includes  Semigroup,  Leftldentity 
Group:  trait 

includes  Monoid,  Leftlnverse 
implies  Rightldentity,  Rightlnverse 

AbelianSemigroup:  trait  includes  Abelian,  Semigroup 
AbelianMonoid:  trait 

includes  Abelian,  Monoid 
implies  Rightldentity 

AbelianGroup:  trait  includes  Abelian,  Group 
Distributive:  trait 

introduces 

#  +  #:  T,  T  -*■  T 
#*#:  T,  T  -►  T 
asserts  for  all  (  x,  y,  2:  T  ] 

x*(y  +  z)  =  ( x*y )  +  (x*z) 

(y  +  z)*x  =  O'*  Jr)  +  (r*x) 
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Staple  Numeric  Types 
Ordinal:  trait 

includes  PartialOrder  with  [  =  for  .eq,  Ord  for  T  J, 
OiderEquivalence  with  [  =  for  .eq,  Ord  for  T  ) 
introduces 

first:  -*■  Ord 
succ:  Ord  -*■  Ord 

asserts  Ord  generated  by  (  first,  succ  ] 

Ord  partitioned  by  [  1 

for  all  (  x  y:  Ord  ] 
fust  x 
~(succ(jc)  ^  first) 
succ(jc)  <  succO')  ~  x  <  y 
implies  TotalOrderWithEquality  with  [  Ord  for  T  ] 
converts  [  <.  =  ] 

Cardinal:  trait 

imports  Ordinal  with  [  0  for  first.  Card  for  Ord  ] 
includes  DerivedOrders  with  [  Card  for  T  ] 
introduces 

1:  —  Card 

#  +  #:  Card,  Card  -*  Card 
it* it:  Card,  Card  -*■  Card 
#©#:  Card,  Card  -»  Card 
constrains  1  so  that  1  =  succ(O) 
constrains  +,  •  so  that  for  all  [  x,  y:  Card  ] 
x  +  0  =  x 

x  +  succO)  =  succ(x  +  y) 
x*0  =  0 

jr*succ(y)  =  x  +  (x*y) 
constrains  0  so  that  for  all  {  x,  y:  Card  ] 

0  ©  jr  =  0 
x  ©  0  =  x 

succfjc)  ©  succO)  =  x  ©  y 
implies  Cardinal 

Card  generated  by  [  1,  +,  ©  1 
Card  partitioned  by  [  >  ],  by  [  =  J,  by  [  <  ),  by  l  >  ] 
for  all  [  x  y:  Card  ]  x  <  y  =  ((or  ©  y)  =  0) 
converts  ( 1,  ©,  +,  *,  =,  <,  >,<,>] 
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Cardinal:  trait  %  Alternate  definition  for  comparison 

includes  AbelianMonoid  with  [  4-  for  O,  0  for  unit.  Card  for  T  ), 
AbelianMonoid  with  (  *  for  0, 1  for  unit.  Card  for  T  J, 
Distributive  with  ( Card  for  T  J, 

Ordered  with  [  Card  for  T  ] 
introduces 

#©#:  Card,  Card  -*  Card 
succ:  Card  -*  Card 
asserts  Card  tenanted  by  [  0, 1,  +  ] 
for  all  I  x,  y  :  Card  ] 
x  <  (x  +  1) 

(x  +  y)Qy=  x 
0©  x  =  0 
succ(x)  =  X  +  1 
t— piffT  Cardinal 
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t  Data  Structures 

Pun  trait 

introduces 

<#,  #>:  Tl,  T2  -►  C 

#  .first:  C  -*  Tl 

#  .second:  C  -*  T2 
asrarts  C  generated  by  [  <#.  #>  ] 

C  partitioned  by  ( .first,  .second  ] 

for  all  [  /•  Tl,  x  T2] 

<f,  s>.first  =  f 
<f,  s>  second  =  s 
{■plies  converts  [  .first,  second  ] 

Triple:  trait 


<#.  #,  #>:  Tl,  T2,  T3  C 
#  .first:  C  -*•  Tl 
#.  second:  C  -*  T2 
#. third:  C  -*  T3 

asserts  C  generated  by  [  <#,  #,  #>  ] 

C  partitioned  by  { .first,  second,  .third  ] 
for  afl  [  /•  Tl,  r  T2,  /:  T3  ) 

<f,  s,  tXfirst  =  f 
<f,  s,  t>.second  =  s 
<f,  s,  tXthird  =  t 

fcnpHes  converts  [  .first,  .second,  .third  } 

FiniteMapping:  trait 

«— a  Equality  with  [  Index  for  T  ] 
introduces 

new:  -*  C 

bind:  C,  Index,  E  -*  C 
#[#]:  C.  Index  -*  E 
defined:  C,  Index  -*  Bool 
asserts  C  generated  by  (  new,  bind  ] 

C  partitioned  by  [  #[#],  defined  ] 
constrains  C  so  that 

for  aO  I  c:  C,  i,  il:  Index,  e:  E  ] 

bind(c,  //,  eXil  =  if  i  =  il  then  e  else  c{j] 
~defined(new.  i) 

defined(bind(c,  il,  e),  i)  =  (»  =  il)  \  defined(c,  i) 
implies  converts  [  #[#],  defined  j 
exempts  for  aU  [  i:  Index  ]  new(;] 
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C— tainer  Properties 


Container:  trait 


new:  -*  C 
insert:  C,  E  -*  C 

asserts  C  generated  by  [  new,  insert  ] 

Singleton:  trait 

assume  i  Container 
introdnces  singleton:  E  -*  C 
constrains  singleton  so  that  for  all  I  e:  E 1 
singleton(tf)  =  insert new.  e) 
hnpHnr  converts  [  singleton  j 

IsEmpty:  trait 

assaroes  Container 
introduces  isEmpty:  C  -*  Bool 
asserts  for  all  ( a  C.  e-  E  ] 
isEmpty(new) 

~isEmpty(insert(c,  e» 
implies  converts  [  isEmpty  j 

Size:  trait 

amames  Container 
imports  Cardinal 
introduces  size:  C  -*•  Card 
constralas  size  so  that 
size(new)  =  0 

AdditiveSize:  trait 

aanunes  Container 
inchides  Size 

constrains  size,  insect  so  that  for  all  {  c:  C.  e:  E 1 
size(insert(c,  e))  =  size(c)  +  1 
implies  converts  (  size  ] 

Join:  trait 

assumes  Container 
introduces  #  .join#:  C,  C  -*•  C 
constrains  .join  so  that  for  all  [  c,  cl:  C,  e:  E  ] 
c  .join  new  =  c 

c  Join  insert(c/.  e)  =  insert(c  Join  cl,  e) 

implies  converts  [  Join  ] 

EtementEquality:  trait  imports  Equality  with  [  E  for  T  ] 

Member  trait 


assumes  Container,  ElementEquality 
introduces  #€#:  E.  C  -*  Bool 
constrains  €,  insert  so  that  for  all  (  c:  C,  e,  el:  E  ] 
~(e  €  new) 

e  €  insert (c,  el)  =  (e  =  el)  |  (e  €  c) 
implies  converts  [  €  ] 
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EkmCount:  trait 

hums  Container,  ElementEquality 
{■ports  Cardinal 
introduces  count:  C,  E  -*  Card 
constrains  count,  insert  so  that  for  all  [  e,  el:  E,  c:  C  ] 
count(new,  e)  =  0 

count(insert(c,  e),  el)  =  count(c,  e)  +  (if  e  =  el  then  1  else  0) 
implies  converts  [  count  ] 

Delete:  trait 

■■nmrs  Container 
introduces  delete:  C,  E  -*•  C 
constrains  delete  so  that  for  all 

Containment:  trait 

■monies  Container 
includes  PartiallyOrdered  with  [ 
constrains  C  so  that  for  all  [  e: 
implies  for  all  [  c:  C  ] 

Next:  trait 

assumes  Container 
introduces  next:  C  -*  E 
constrains  next,  insert  so  that  for  all  |  e:  E  ]  next(insert(new.  e»  =  e 

exempts  next(new) 

Rest:  trait 

assumes  Container  ^ 
introduces  rest:  C  -*  C 

constrains  rest,  insert  so  that  for  all  [  e:  E  ]  res t( insert new,  e))  =  new 

exempts  rest(new) 

Remainder:  trait 

assumes  Container.  Rest 
imports  Cardinal 

introduces  remainder:  C.  Card  -►  C 
constrains  remainder  so  that  for  all  [  c:  C,  i:  Card  ) 
remainder^,  0)  =  c 

remainderfc,  /  +  1)  =  remainder rest(c),  i) 
implies  converts  { remainder  ] 

Index:  trait 

asromes  Container,  Next.  Rest 
imports  Cardinal 
introduces  #(#]:  C,  Card  -»  E 
constrains  #[#]  so  that  for  all  [  c:  C,  L-  Card  ] 
cfl]  =  next(c) 

40  +  1)]  =  rest(c)(il 
implies  converts  (  #(#]  ] 
exempts  for  all  [  c;  C  ]  40] 


[  e:  E  ]  delete(new,  e)  =  new 


C  for  <.  D  for  >,  Q  for  2  for  C  for  T  ] 
E  c:  C  ]  c  Q  insertfc.  e) 

new  £  c 
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Bag:  trait 

assumes  EkmentEquality 

imports  BagBasics 

includes  CoIlectionEx  tensions 

Implies  Abelian  with  [  U  for  O,  C  for  T  ] 

converts  [  size,  delete,  count,  €.  U,  {#},  isEmpty,  =,  C,  D,  C,  2  ] 

Enumerable:  trait 

imports  IsEmpty,  Next,  Rest 
fochdes  Container 

constrains  C  so  that  C  partitioned  by  [  next,  rest,  isEmpty  ] 

InsertionOrdered:  trait  %  For  assuming  HStack  or  Queue" 

includes  Enumerable 
introduces  isFIFO:  -*  Bool 

coBstrains  next,  rest,  insert  so  that  for  all  [  c:  C,  e:  E] 

next(insert(c,  e))  -  if  isEmpty(c)  |  isFIFO  then  e  else  next(c) 
rest(insert(c,  e ))  =  if  isEmpty(c)  |  isFIFO  then  c  else  insert(rest(c),  e) 
implies  converts  (  next,  rest  ] 

Stack:  trait 

includes  InsertionOrdered  with  [  push  for  insert,  top  for  next,  pop  for  rest, 
true  for  isFIFO  ] 
implies  for  all  [  stk:  C,  e:  E  ] 
top(push(s/fc  e»  =  e 
pop(push(j/A,  e))  —  stk 

Queue:  trait 

includes  InsertionOrdered  with  [  first  for  next,  false  for  isFIFO  ] 
implies  for  all  [  q:  C.  e:  E  ] 

first( insert e))  -  if  isEmpttfg)  then  e  else  Rist(q) 

rest( insert( <?,  e))  =  if  isEmptytf)  then  new  else  insert(rest(4).  e) 

Dequeue:  trait 

includes  Stack  with  [  insert  for  push,  first  for  top,  rest  for  pop  ], 

Stack  with  (  enter  for  push,  last  for  top,  prefix  for  pop  ] 
constrains  C  so  that  for  all  [  c:  C,  e,  el:  E  ] 
insert(new,  e)  =  enter! new,  e) 
insert(enter<c,  e),  el)  =  enter<insert(c,  el),  e) 
implies  Queue,  Queue  with  [  enter  for  insert,  last  for  first,  prefix  for  rest  ] 
converts  ( insert,  first,  last,  rest,  prefix],  [  enter,  first,  last,  rest,  prefix  ] 

Sequence:  trait 

imports  Dequeue,  AdditiveSize 
includes  Index  with  [  first  for  next  ], 

Join  with  [  ||  for  .join  ] 
implies  C  partitioned  by  (  size,  #[#]  ] 

SubSequence:  trait 

hnports  Sequence 

includes  Remainder  with  [  #[#...]  for  remainder  ], 

Remainder  with  [  #[...#]  for  remainder,  prefix  for  rest  ] 
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Container 

SetBasics:  trait 

bmh  BementEquality,  Container  with  [  {}  for  new  ] 
hthto  Size  with  [  {}  for  new  J, 

Member  with  [  {}  for  new  ] 
introduce*  delete:  CE-»C 
constraks  C  so  that 

C  partitioned  by  [  €  ] 
for  all  [  r  C,  e,  el:  E  ] 

size(insert(i,  e))  =a ze(s)  +  (if  e  €  s  then  0  else  1) 
el  €  deleted  e)  =  (el  €  s)  A  (**(e  =  el)) 
implies  Delete  with  [  {}  for  new  ] 
converts  [  size,  delete,  €  ] 

BagBasics:  trait 

asswmes  BementEquality,  Container  with  [  {}  for  new  ] 
imports  AdditiveSize  with  [  {}  for  new  j, 

ElemCount  with  [  {}  for  new  ] 
includes  Member  with  [  {}  for  new  ] 
introduces  delete:  C,  E  -*  C 
constrains  C  so  Oat 

C  partitioned  by  [  count  ] 
for  all  l  Ik  C,  e,  el:  E  ] 

count(delete(6,  e),  el)  =  count(6,  el)  -  (if  e  =  el  then  1  else  0) 
implies  Delete  with  [  {}  for  new  ] 
converts  [  size,  delete,  count.  €  ] 

CollectionEx tensions:  trait 

assumes  BementEquality,  Container  with  [  {}  for  new  ] 
imports  IsEmpty  with  [  {}  for  new  ], 

Singleton  with  [  {}  for  new,  {#}  for  singleton  ], 

Containment  with  [  {}  for  new  ], 

Join  with  [  {}  for  new,  U  for  .join  ] 
includes  Equality  with  [  C  for  T  ] 
implies  converts  [  {#},  isEmpty,  U  ] 

Setlntersection:  trait 

assumes  SetBasics 
introduces  fl:  C,  C ;  -*•  C 
constrains  C  so  that  for  all  [  *  si:  C,  e.  el:  E  ] 
e  €  (s  H  si)  =  (e  €  s)  A  (e  €  si) 
converts  [  H  ] 

Set:  trait 

assumes  BementEquality 
imports  SetBasics,  Setlntersection 
includes  CollectionEx  tensions 
hnpHes  Abelian  with  [  U  for  O,  C  for  T  ], 

Abelian  with  (  n  for  O,  C  for  T  ] 
converts  [  size,  delete,  €,  H,  U,  {#},  isEmpty,  =,  C,  D,  £,  3  J 
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String:  trait 

iapotts  Character 

includes  Sequence  with  [  length  for  size.  Char  for  E  ] 

Priori tyQueue:  trait 

assumes  TotaJOrder  with  l  E  for  T 1 
{■dudes  Enumerable 

constrains  next,  rest,  insert  so  that  for  all  [  q:  C,  e:  E  ] 
nextfinsertf?,  e))  =  if  isEmpty(^)  then  e 

else  if  next (q)  ^  e  then  next(^)  else  e 
resttfnsertta  «))  =  if  isEmpty(g)  then  new 

else  if  next (q)  ^  e  then  insert(rest(g),  e)  else  q 
implies  converts  [  next,  rest,  isEmpty  ] 


Generic  Operators  on  Containers 

CoerceContainer.  trait 

■isumri  Container  with  [  DC  for  C  ], 

Container  with  {  RC  for  C  ] 
introduces  coerce:  DC  -*  RC 
coustrams  coerce  so  that  for  all  [  dc:  DC.  e:  E  ] 
coerce(new)  =  new 

coerce(insert(dr,  e))  =  insert(coerce(<fc).  e) 
implies  converts  [  coerce  ] 

Reduce:  trait 

assumes  Enumerable. 

Rightldentity  with  [  E  for  T  J, 

Associative  with  [  E  for  T  ] 
introduces  reduce:  C-*E 
constrains  reduce  so  that  for  aO  {  c:  C  1 

reduce(c)  =  if  isEmpty(c)  then  unit  else  next (c)  O  reduce(rest(c)) 
implies  converts  [  reduce  ] 

SomePass:  trait 

assumes  Container 
introduces 

test:  E,  T  -*  Bool 
somePass:  C,  T  -*  Bool 

constrains  somePass  so  that  for  all  [  c:  C,  e:  E,  t:  T  ] 

~somePass(new,  t) 

somePass(insert(c,  e),  t)  =  test(e,  t)  |  somePass(c,  t) 
implies  converts  f  somePass  1 
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ADPss:  trait 


m 


i  Container 


test:  E.T  Bod 
allPass:  C,  T  ->  Bool 

constrains  allPass  so  that  for  all  [  c:  C,  e :  E,  i:  T ) 
aHPass(new,  0 

allPass(insert(c,  e),  0  =  testfe,  0  &  allPass(c,  t) 
hnpBn  converts  [  allPass  ] 


Sift  trait 


Container 


test:  E,  T  -*  Bool 
sift:  C.  T  -*  C 

constrains  sift  so  that  for  all  [  e:  C,  e :  E,  t:  T  ] 
sift(new,  0  =  new 

sift(insert(c,  e),  0  =  if  test(e,  0  then  insert(sift(c,  t),  e)  else  sift(c,  0 
implies  converts  [  sift  ] 

PairwiseExtension:  trait 

assumes  InsertionOrdered 
introduces 

extOp:  C,  C  -*  C 
elemOp:  E,  E  -*  E 

constrains  extOp  so  that  for  all  [  cl,  c2:  C,  el,  e2:  E  ] 
extOp(new,  new)  =  new 

extCHKinsert(c/.  el),  insert(c2,  e2))  =  insert(extOp(c/,  c2),  elemOp(e/.  e2)) 
implies  converts  [  extOp  ] 
exempts  for  all  [  c:  C,  e:  E 1 
extOp(new,  insert(c,  e)\ 
extOpfinsertfc,  e),  new) 

Pointwiselmage:  trait 

assumes  Container  with  [  IX  for  C,  DE  for  E  ], 

Container  with  [  RC  for  C,  RE  for  E  ] 
introduces 

extOp:  DC  -*  RC 
pointOp:  DE  -*  RE 

constrains  extOp  so  that  for  all  (  dc:  DC,  de:  DE  ] 
extOpfnew)  =  new 

extOpfinsertfir,  de))  =  insert(extOp(</c),  pointOp(ie)) 
implies  converts  [  extOp  ] 


1TI1 


V 
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Nonlinear  Structures 

BinaryTree:  trait 

(■ports  Cardinal 

<#>:  E  C 
<#.  #>:  C,  C  C 
#Jeft:  C  -*  C 
#  .right:  C  -*•  C 
size:  C  -*  Card 
isLeaf:  C-+  Bool 
content:  C  -*  E 
constrains  C  so  that 

C  generated  by  ( <#>.  <#.  #>  ] 

C  partitioned  by  [  .left,  .right,  content.  isLeaf  ] 
for  ad  [  /4  ftr  C.  e*  E  ] 

(<//,  rr>).left  =  tl 
(<tl tr>)j ight  =  tr 
size(<e>)  =  1 

size(<l4  tr>)  —  si xc(tl)  +  size(/r) 
isLeaft<e>) 

~isLeafl(<//,  tr>) 
content(<e>)  =  e 

implies  for  aU  [  t:  C  ]  isLeaflr)  =  (size(/)  =  1) 
converts  [  .left  .right,  size.  isLeaf,  content  ] 

exempts  for  afl  [  tl,  tr  C,  e:  E  ]  (<e>)Jeft,  (<e>).right,  content (<//,  tf>) 
BasicGraph:  trait 

assumes  Equality  with  [  Node  for  T  ] 
imports  Set  with  [  NodeSet  for  C.  Node  for  E  ], 

Pair  with  [  Edge  for  C.  Node  for  Tl,  Node  for  T2  ] 
introduces 

empty:  -»  Graph 
addNode:  Graph,  Node  -»  Graph 
addEdge:  Graph,  Edge  -*  Graph 
nodes:  Graph  -*  NodeSet 
adj:  Node,  Graph  -*  NodeSet 
constrains  Graph  so  that 

Graph  generated  by  [  empty,  addNode,  addEdge  ] 

Graph  partitioned  by  [  nodes,  adj  ] 
for  all  [  g:  Graph,  e:  Edge,  n,  nl:  Node  ] 
nodes( empty)  =  {} 

nodes(addNode(g,  n))  =  insert(nodes(g),  n) 

nodes(addEdge(g,  e»  =  insert(insert(nodes(g),  e.  first),  ^.second) 

adlKn,  empty)  =  {} 

adKn,  addNodefg,  nl))  =  adj(fi,  g) 

ad ij(*.  addEdge(g,  e))  = 

if  n  =  (e.  first)  then  insert adj(n,  g),  e.second)  else  adj(n,  g) 
tepUes  converts  (  nodes,  adj  ] 
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Connectivity:  trek 

ammnei  Equality  with  [  Node  for  T  ],  BasicGraph 
introdnces 

reach:  NodeSet,  Graph  -*■  NodeSet 
aQReach:  NodeSet,  NodeSet,  Graph  -*•  Bool 
connected:  Graph  -*  Bool 
constrains  reach,  aQReach,  connected  so  that 

for  ail  [  g;  Graph,  e:  Edge,  ns,  nsl:  NodeSet,  k  Node  ] 
reachC/u,  empty)  =  {} 
nsch(ns,  addNode(g,  «))  =  reachfns,  g) 
aUReach({},  ns,  g) 
aUReach(insert(nj;  n),  nsl,  g)  = 
allReachfns,  nsl,  g)  ft  ( nsl  Q  reach({n},  g)) 
connected(g)  =  allReach(nodes(g),  nodes(g),  g) 
implies  converts  [  aQReach.  connected  ] 

Graph:  trait 

Equality  with  [  Node  for  T  ] 
imports  BasicGraph 
includes  Connectivity, 

Connectivity  with  {  stronglyConnected  for  connected,  pathReach  for  reach. 
aQPathReach  for  aQReach  ] 
constrains  reach,  aQReach,  connected  so  that 
for  all  [  g:  Graph,  e:  Edge,  ns:  NodeSet  ] 

teachfns,  addEdge(g,  e»  =  reachfnx,  g)  U 

(if  (e.first)  €  ns  then  insert(reach({(e.secon d)},  g),  (esecoad)) 
else  if  (e.second)  €  ns  then  insert(reach({(e.first)},  g),  (e.first)) 
else  {}) 

constrains  pathReach,  aQPathReach,  stronglyConnected  so  that 
for  all  [  g-  Graph,  e:  Edge,  ns:  NodeSet  ] 

pathReachf/u,  addEdge(g,  e))  =  pathReachf/u,  g)  U 
(if  (e.fint)  €  ns 

then  insert(pathReach({(e.second)}.  g).  (esecoad)) 
else  {}) 

iaqplies  converts  [  reach,  aQReach,  connected,  pathReach,  aQPathReach. 
stronglyConnected  1 
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Hap,  Fields,  and  Numben 
Ring:  trait 

includes  AbelianGroup  with  [  +  for  O,  0  for  unit,  -  #  for  inv  J, 
Semigroup  with  (  *  for  O  J. 

Distributive 

Ring  WithU nit:  trait 

fochdes  Ring,  Identity  with  [  *  for  0. 1  for  unit  ] 

Infixlnvene:  trait 

taMfom#?#:  T,  T  —  T 
constrains  #0#  so  that  for  all  [  x,  y:  T  ] 
x  0  y  —  xO  in  v(y) 
implies  coaverts  [  #0#  ] 

Integer:  trait 

includes  RingWithUnit  with  { Int  for  T  J, 

Ordered  with  ( Int  for  T  l 

Infixlnvene  with  [  +  forO,  -#  for  inv,  —  for  0,  Int  for  T  ] 
asserts  Int  generated  by  [  1,  +,  -  #  ] 
for  all  [  x-  Int  ] 

x  <  (x  +  1) 

implies  Rational  without  I  ‘1,  /  )  with  [  Int  for  R  ] 
converts  [  0,  •  #- #,  =,  <,  >  ] 

Field:  trait 

includes  RingWithUnit 
introduces  #** :T-»T 
constrains  *, -1  so  that  for  all  (  x:  T  ] 

(x  =  0)  |  ((x*(x'1))  =  I) 
exempts  (T1 

Rational:  trait 

includes  Field  with  [  R  for  T  l 
Ordered  with  [  R  for  T  ], 

Infixlnvene  with  [  +  for  O,  -  #  for  inv,  -  for  0,  R  for  T  J, 
Infixlnvene  with  [  •  for  O,  #'1  for  inv,  /  for  0,  R  for  T  ] 

asserts 

R  generated  by  [  1,  +,  -  1 J 

for  all  I  x,  y.  v  R  1 
0  <  1 

((x  +  z)  <  O  +  z»  =  (x  <  y) 

(x  =  0)  |  ((0  <  (x1))  =  (0  <  x)) 
implies  converts  f  0,  •,#-#,  /,  =  ,  <.  >  ] 


so 
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Lattices 

ExtremalBound:  tnk 

aannati  PtftuJOrder 

iadnto  AbelianSemigroup  with  ( .gib  for  O  ) 
coastnins  .gib  so  that  for  all  [  x,  y,  z:  T 1 
(x  .gib  y)  <,  x 

((x  £  x)  &  (z  £  y))-*(z  <,  (x  .gib  >)) 

Semilattice:  trait 

includes  PartiallyOrdered, 

Extremal  Bound, 

Extremal  Bound  with  [  >  for  .lub  for  .gib  ] 
introduces  ±:  -*  T 
coBstrahu  1  so  that  for  all  [  x:  T ) 
x  £  -L 

implies  AbelianMonoid  with  {  -L  for  unit,  .lub  for  O  ] 
Lattice:  trait 

mdndes  Semilattice 
introduces  T:  -*T 


constrains  T  so  that  for  all  [  x:  T  ] 
x£T 


I 
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Emunented  Data  Types 

Enumerated:  trait 

imports  Ordinal 
iadades  Ordered 
iatroduces 

first  -*■  T 
last  -*T 
succ:  T  -»  T 
pred:  T  —  T 
ord:  T  -*■  Ord 

asserts  T  generated  by  [  first,  succ  ] 

T  partitioned  by  [  ord  ] 
for  ail  [  x.  y;  T  ] 

ord(  first)  =  first 

ord(succ(x»  =  if  x  =  last  then  ord(last)  else  succ(ord(x)) 
pred(succ(x))  =  if  x  =  last  then  pred(last)  else  x 
x  <,  y  =  ord(x)  <;  ordO) 

Implies  T  generated  by  [  last,  pred  ] 
for  all  [  x-  T 1 

succ(pred(x))  =  if  x  *  first  then  succ( first)  else  x 
first  ^  x 
x  ^  last 

converts  l  =.  <,  >  ) 

Rainbow:  trait 

indndes  Enumerated  with  [  Color  for  T ) 
fotradnees 

red:  -*  Color 
orange:  -*  Color 
yellow:  -*  Odor 
green:  -*  Color 
blue:  -*  Color 
violet:  -*  Color 

Color  generated  by  (  red,  orange,  yellow,  green,  blue,  violet  ] 

first  =  red 

last  =  violet 

succfred)  =  orange 

succ(orange)  =  yellow 

succ(yellow)  =  green 

succfgreen)  =  blue 

succ(btue)  =  violet 

bnpHrt  converts  [  pred,  last,  ord,  =,  <,,  >,  <,  >,  red,  orange,  yellow,  green,  blue, 
violet  J, 

I  succ,  first,  ord,  =,  <,  >,  red,  orange,  yellow,  green,  blue,  violet  ] 

Character  trait  indndes  Enumerated  with  [  Char  for  T  ] 

%  For  each  programming  language  there  will  be  mappings  from  character  and  string  constants  to 
%  terms  in  die  rfured  language.  Because  of  the  variety  of  character  orderings  and  notations  for 
%  constants,  these  definitions  are  not  likely  to  be  portable  across  programming  languages. 
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Display  Traits 

%  The  fidlowing  traits  represent  a  fairly  straightforward  translation  of  the  specifications  in 
%  “Formal  Specification  as  a  Design  Tool”  (CSL-80-1).  We  have  not  attempted  to  improve  the 
%  design  presented  there,  merely  to  translate  it  into  Larch. 

Coordinate:  trait  introduces  minus:  Coordinate,  Coordinate  -*•  Coordinate 
Illumination:  trait  introduces  combine:  Illumination,  Illumination  -*  Illumination 
Boundary:  trait  introduces  apply:  Boundary,  Coordinate  -*  Bool 
Transform:  trait  introduces  apply:  Transformation,  Coordinate  -*  Coordinate 
Displayable:  trait 
introduces 

appearance:  T,  Coordinate  -»  Illumination 
in:  T,  Coordinate  -*  Bool 

Picture:  trait 

assumes  Boundary,  Transform,  Illumination, 

Displayable  with  [  Contents  for  T  ] 
includes  Displayable  with  [  Picture  for  T  ] 

introduces  makePicture:  Contents,  Boundary,  Transformation  -*  Picture 
constrains  Picture  so  that 

Picture  generated  by  [  makePicture  ] 

for  all  [  cn:  Contents,  b:  Boundary,  t:  Transformation,  c±  Coordinate  ] 
appearance(makePicture(c/t,  b,  t),  cd)  — 
appearance(cR,  applet,  cd)) 
in(makePicture( cn,  b,  t ),  cd)  =  apply(6,  cd) 
implies  converts  [  appearance:  Picture,  Coordinate  -*  Illumination, 
in:  Picture,  Coordinate  -*  Bool  ] 

Contents:  trait 

assumes  Coordinate,  Illumination,  Displayable  with  [  Component  for  T  ] 

includes  Displayable  with  [  Contents  for  T  ] 

introduces 

empty:  -*■  Contents 

addComponent:  Contents,  Component,  Coordinate  -»  Contents 
constrains  Contents  so  that 

Contents  generated  by  [  empty,  addComponent  ] 
for  all  [  cn:  Contents,  cm:  Component,  cd,  cdl:  Coordinate  ] 
appearance(addComponent(cH,  cm,  cdl),  cd)  = 
if  in(cm,  minus(c4  cdl)) 
thro  (if  in(cn,  cd) 

then  combine(appearance(cm,  minus(c<f,  cdl)), 
appearance(c/i,  cd)) 
else  appearance! cm,  minus(c<4  cdl))) 
else  appearanc e(cn,  cd) 

~in(empty,  cd) 

in(addComponent(cn,  cm,  cdl),  cd)  = 
in (cm,  minus(cd,  cdl))  |  in(cn,  cd) 

implies  converts  (  appearance:  Contents,  Coordinate  -»  Illumination, 
in:  Contents,  Coordinate  -*  Bool  1 
exempts  for  all  [  c±  Coordinate  ]  appearance!  empty,  cd) 
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Component:  trait 

wain  DispUyable  with  [  View  far  T  J. 

DispUyable  with  [  Text  for  T  J. 

DispUyable  with  (  Figure  for  T  J 

Ucindes  CompooentCoercion  with  I  View  for  T,  coeiceView  for  coerce'), 
CompooentCoercion  with  ( Text  for  T,  coeiceText  for  coerce  J, 
CompooentCoercion  with  [  Figure  for  T,  coerce  Figure  for  coerce  ] 

CompooentCoercion:  trek 
lanwri  Displayable 

hthte  DispUyable  with  [  Component  for  T ) 
introduces  coerce:  T  -»  Component 
constrains  Component  so  that  for  al  [  u  T,  at  Coordinate ) 
appearance(coCTce( cd )  =  appearance(/,  cd) 
in(coeice(/X  cd)  =  in(A  cd) 

View:  trait 

aitanift  DispUyable  with  [  Picture  for  T  J, 

Equality  with  [  Pictureld  for  T  J, 

Container  with  [  IdList  for  C  Pictureld  for  E  J, 

Coordinate 

iadndes  DispUyable  with  {  View  for  T  ] 


empty:  -*■  View 

addPicture:  View,  Coordinate,  Pictureld,  Picture  -*•  View 
findPictures:  View,  Coordinate  -♦  IdList 
deletePicture:  View,  Pictureld  -*  View 
constrains  View  so  that 

View  generated  hy  [  empty,  addPicture  ] 

for  all  [  v;  View,  cd,  all:  Coordinate,  id,  idl:  Pictureld,  p:  Picture  ] 
appearance(addPicture(v,  cdl,  id,  p),  cd)  = 

if  in(p,  minus(cd  cdl))  then  appearance(p,  minus(c<L  cdl)) 
else  appearance(v,  cd) 

~in(empty,  cd) 

in(addPicture(v,  cdl,  id,  p),  cd)  =  (in (p,  minusfed'  cdl))  |  in(v,  cd)) 
findPictures(empty,  cd)  =  new 
findPictures(adclPicture(  v,  cdl,  id,  p),  cd)  = 

if  in(p,  minus(c<L  cdl))  then  insert(uL  findPictures(v,  cd)) 
else  findPictures(v,  cd) 
deletePicture(empty,  id)  =  empty 
deletePicture(addPicture(y,  cdl,  idl,  p),  id)  = 

if  id  .eq  idl  then  v  else  addPicture(deletePicture(v,  id),  cd,  idl,  p) 
invites  converts  [  findPictures,  deletePicture, 

appearance:  View,  Coordinate  -*  Illumination, 
in:  View,  Coordinate  -»  Bool ) 
exempts  for  ail  [  cd i  Coordinate  ]  appearance(empty,  cd) 


DispUy:  trait 


ss  Boundary,  Transform,  Illumination,  Coordinate, 
Equality  with  [  Pictureld  for  T  ], 

Container  with  ( IdList  for  C.  Pictureld  for  E  ] 
s  Picture,  Contents,  Component,  View 
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